INGENIERÍA INFORMÁTICA PRÁCTICAS DE REDES PROTOCOLO TCP. José Luis González Sánchez CURSO

Transcripción

1 INGENIERÍA INFORMÁTICA PRÁCTICAS DE REDES CURSO PROTOCOLO TCP José Luis González Sánchez 1

2 1 HERRAMIENTAS UTILIZADAS SCRIPTS TCL SINTAXIS BÁSICA VARIABLES COMANDOS ANIDADOS UTILIZACIÓN DE COMILLAS Y LLAVES ESTRUCTURAS DE CONTROL DE DÓNDE VIENEN LOS COMANDOS? OTRAS CARACTARISTICAS MÁS INFORMACIÓN SCRIPTS TCL PARA CREAR ESCENARIOS PARA NS LOS EVENTOS MONITORIZACIÓN DE UNA COLA CREACIÓN DE FICHEROS DE TRAZA PARA Xgraph ASPECTOS GENERALES DEL PROTOCOLO TCP CONTROL DE FLUJO MEDIANTE MECANISMO DE VENTANA DESLIZANTE CONTROL DE CONGESTIÓN DEL PROTOCOLO TCP CÓMO SE CONTROLA LA CONGESTIÓN? EVOLUCION DEL CONTROL DE CONGESTION IMPLANTACIÓN DE LAS DISTINTAS VERSIONES DE TCP THROUGTPUT Y PROBABILIDAD DE PÉRDIDA ADAPTACIÓN DEL ANCHO DE BANDA ESCENARIO MULTIPUNTO MULTIPUNTO

3 1. HERRAMIENTAS UTILIZADAS. Este estudio se apoya fundamentalmente en el uso de la herramienta NS (Network Simulator) que se va a usar para analizar el comportamiento del protocolo de la capa de transporte TCP. Hay múltiples versiones disponibles de NS en la red; además de las versiones que se proporcionan en la página de la asignatura ( ), en donde se pueden encontrar paquetes de instalación precomplidados, preparados para ser instalados bajo distintos tipos de sistemas (all-in-one), o componentes de estos paquetes por separado. NS es una aplicación desarrollada para entornos Unix /Linux, y se recomienda la utilización de estos sistemas operativos para la instalación y ejecución de la aplicación, aunque también pueden usarse simuladores de Unix como puede Cygwin. Cygwin es un programa que simula un sistema Unix dentro de un sistema Windows, y puede obtenerse de Desde este sitio puede obtenerse un ejecutable que se encarga de buscar en Internet los espejos desde donde instalar todos los componentes de Cygwin. Algunos de los componentes necesarios a incluir en la instalación de Cygwin son Xfree86-base, Xfree86-bin, Xfree86-prog, Xfree86-lib, Xfree86-etc; aunque, si no se ha elegido la opción de instalar todo, durante la instalación de NS se solicitará la instalación de varios componentes más. En cualquier momento se tiene acceso a la instalación de estos componentes con el ejecutable de instalación de Cygwin. Es recomendable que la instalación de Cygwin se haga en el directorio C:\cygwin y asegurarse de que no hay espacios en blanco en el path de instalación. Una vez instalado Cygwin, o conseguido el software de NS para Unix y/o Linux, los pasos a seguir son los siguientes: Copiar el archivo ns-allinone-2.27.tar.gz en el directorio home de Linux o de Cygwin; habitualmente algo como C:\cygwin\home\nicolas Ejecutar Cygwin ( también se puede lanzar el Xfree con el comando startx) Desde un prompt ejecutar los siguientes comandos: gzip d c ns-allinone-2.27.tar.gz tar xvf cd ns-allinone-2.27 /install Comenzará la instalación, que durará varios minutos. Es posible que el instalador avise de la falta el paquete diff, pero este mensaje puede ser ignorado ya que probablemente el paquete esté ya instalado; para comprobarlo, puede teclearse el comando diff v y podrá verse la versión de este paquete y no un error. Si el aviso es sobre cualquier otro paquete habrá que localizarlo e instalarlo con el ejecutable de instalación de Cygwin. Actualizar el fichero ~/.bashrc añadiendo los siguientes comandos: export NS_HOME=/home/xxx/ns-allinone-2.27/ export PATH=$NS_HOME/tcl8.4.5/unix:$NS_HOME/tk8.4.5/unix:$NS_HOME/bin:$PATH export LD_LIBRARY_PATH=$NS_HOME/tcl8.4.5/unix:$NS_HOME/tk8.4.5/unix:\ $NS_HOME/otcl-1.8.:NS_HOME/lib:$LD_LIBRARY_PATH export TCL_LIBRARY=$NS_HOME/TCL8.4.5/library Donde /home/xxx/ns-allinone-2.27/ comando pwd. deberá ser reemplazado por lo que devuelva el 3

4 Nota: la descripción completa y detallada de los pasos a dar en la instalación de esta y otras versiones de NS para Cygwin pueden encontrarse en: Si la instalación es realizada sobre un sistema Linux es, con diferencia, más rápida que la descrita. Básicamente con descomprimir el paquete all-in-one correspondiente y ejecutar el script./install, ya estaríamos compilando los componentes. Sea cual sea la opción elegida, una vez instalado NS, se podrá ejecutar el comando: $ns <tclscrip> y surgirán las ventanas gráficas con el resultado del script tcl introducido. Los componentes que se instalan y configuran para la utilización de NS son: Tcl Tk Otcl TclCL Ns TclDebug Nam Xgraph GT-ITM Topology SGB CWEB ZLib 4

5 2. SCRIPTS TCL 2..1 SINTAXIS BÁSICA Los scripts TCL se construyen a partir de comandos, separados por ; o en líneas independientes. Los comentarios se indican con el carácter #. Todos los comandos tienen el mismo formato, por ejemplo: expr Cada comando TCL consiste en una o varias palabras donde la primera de ellas se corresponde con el nombre del comando y las otras son los argumentos de ese comando. En este caso, el comando expr devuelve como un string el resultado de la operación aritmética indicada en los parámetros. Todos los comandos TCL devuelven un resultado, aunque se trate de un string vacío VARIABLES Para almacenar y leer valores en una variable se utiliza el comando set, por ejemplo: set x 32 Almacena el valor 32 en la variable x, o bien, set x Con el que se retorna el valor contenido en la variable x. No es necesaria la declaración de variables ni tipos en TCL ya que cada variable es creada automáticamente la primera vez que toma un valor. Para utilizar el valor de una variable en un comando, se indica de la siguiente manera: expr $x*3 Las letras y dígitos que siguen al símbolo $ son tomadas como el nombre de una variable y el comando opera con el valor que ésta representa. Ejemplo: set cmd expr set x 11 $cmd $x*$x 2..3 COMANDOS ANIDADOS. Para anidar comandos se utilizan los corchetes. Por ejemplo: set a 44 set b [expr $a*4] 5

6 2..4 UTILIZACIÓN DE COMILLAS Y LLAVES Si observamos los siguientes comandos: set x 24 set y 18 set z "$x + $y es [expr $x + $y]" Tas la evaluación de estos 3 comandos, la variable z tendrá el valor es 42, es decir, se almacena en la variable z una cadena de caracteres pero utilizando el valor de las variables y expresiones que estén contenidas en dicha cadena; sin embargo, si utilizamos las llaves: set z {$x + $y es [expr $x + $y]} el valor de la variable z es: $x + $y es [expr $x + $y] 2..5 ESTRUCTURAS DE CONTROL Las estructuras de control en TCL son también comandos que toman scripts TCL como argumentos. El siguiente ejemplo muestra un procedimiento que eleva una base a una potencia entera: proc potencia {base p} { set result 1 while {$p > 0} { set result [expr $result * $base] set p [expr $p - 1] } return $result } Este script consiste en un único comando, proc. El comando proc toma 3 argumentos: el nombre del procedimiento, una lista de nombres de argumentos, y el cuerpo del procedimiento, que es un script TCL. El comando proc crea un nuevo comando TCL llamado potencia que toma dos argumentos. Ahora se podría invocar el comando potencia de alguna de estas maneras: potencia 2 6 potencia cuando se invoca potencia, el cuerpo del procedimiento es evaluado accediendo a sus argumentos como variables: base y p El script correspondiente al cuerpo del procedimiento contiene 3 comandos TCL: set, while, y return. El comando while tiene dos argumentos, una expresión ($p>0) y un cuerpo, que como se puede intuir, es otro script TCL. 6

7 2..6 DE DÓNDE VIENEN LOS COMANDOS? Los comandos TCL son creados de tres formas. Un grupo de comandos es proporcionado por el intérprete TCL, estos comandos reciben el nombre de builtin commands. El segundo grupo de comandos es creado utilizando el mecanismo de extensión TCL. TCL proporciona APIs que permiten crear un nuevo comando mediante la escritura de un command procedure en C o C++. Tras registrar el nuevo comando en el intérprete TCL se podrá utilizar este comando como si fuera un builtin command, ya que, de hecho, los builtin commands son implementados utilizando este mecanismo de extensión; los procedimientos de sus comandos son simplemente parte del TCL library. También existen numerosos paquetes de extensión (extension packages que pueden ser incorporados a cualquier aplicación TCL. Una de las extensiones más conocidas es Tk, que proporciona utilidades muy potentes para la creación de interfaces gráficas. Otras extensiones proporcionan programación orientada por objetos, acceso a base de datos, etc. El tercer grupo de comandos consiste en procedimientos creados con el comando proc, como el procedimiento potencia anterior. Normalmente las extensiones son utilizadas para funciones de bajo nivel donde es conveniente la programación en C, y los procedimientos son utilizados para funciones de más alto nivel, donde es más sencillo utilizar TCL OTRAS CARACTERÍSTICAS. TCL tiene muchos otros comandos además de los utilizados en los ejemplos anteriores: Más estructuras de control como if, for, foreach, y switch. Manipulación de strings Entrada/Salida, incluyendo ficheros, sockets y dispositivos como puertos serie. Gestión de ficheros (lectura y escritura de atributos, copia, borrado, directorios...) Se pueden ejecutar otras aplicaciones con el comando exec y comunicarse con ellas mientras se ejecutan. Creación y manipulación de listas y arrays. Manipulación de fecha y hora. Eventos: TCL permite a los scripts esperar a que ocurran eventos como la disponibilidad de datos en un socket MÁS INFORMACIÓN Tcl books: A short summary of Tcl syntax Detailed manual entries for Tcl and Tk SCRIPTS TCL DE CREACIÓN DE ESCENARIOS PARA NS Ns utiliza un script TCL que implementa un escenario, para crear unos ficheros que contienen la información necesaria a partir de la cual se representa gráficamente el comportamiento de la red. El esquema básico de un script TCL para implementar un escenario puede ser el siguiente: En primer lugar se necesita crear un objeto simulador; para ello se utiliza el siguiente comando: 7

8 set ns [new Simulator] Se puede abrir un fichero que será utilizado para visualizar los datos de traza del Nam: set nf [open out.nam w] $ns namtrace-all $nf El primer comando abre el fichero out.nam para escritura y le asigna el identificador nf; y en la segunda línea se indica al objeto simulador creado que escriba en este fichero todos los datos de la simulación que sean relevantes para Nam. El siguiente paso consiste en crear el procedimiento finish, cuyo cometido será cerrar todos los ficheros de traza y ejecutar Nam: proc finish {} { global ns nf $ns flush-trace close $nf exec nam out.nam & exit 0 } Con la siguiente línea se le dice al objeto simulador que ejecute el procedimiento finish a los 5 segundos de simulación. $ns at 5.0 "finish" El comando at proporciona una forma simple de indicar eventos en NS. La última línea ejecuta la simulación: $ns run El código descrito hasta ahora supone el esqueleto básico de cualquier script TCL para ns; sin embargo, no está completo, ya que no se han definido eventos ni objetos, es decir, nodos, enlaces, envío de datos, etc. Este código debe ser introducido antes de la línea que ejecuta ns ($ns run) o incluso mejor antes de la línea ($ns at 5.0 "finish") Las siguientes dos líneas definen dos nodos: set n0 [$ns node] set n1 [$ns node] El comando $ns node crea un objeto nodo, y se le asignan los identificadores n0 y n1. La siguiente línea conecta dos nodos: $ns duplex-link $n0 $n1 1Mb 10ms DropTail Esta línea indica al objeto simulador que conecte los nodos n0 y n1 con un enlace duplex con un ancho de banda de 1 Megabit, un retardo de 10 ms y una política de gestión de cola DropTail. 8

9 Hasta ahora sólo podemos ver la topología de la red, pero no sucede nada, el siguiente paso es enviar algún dato desde un nodo a otro. En ns, los datos siempre se envían de un agente a otro, por eso el siguiente paso es crear un objeto agente que envíe datos desde el nodo n0, y otro objeto agente que reciba datos en el nodo n1. #Crea un agente UDP y lo asigna al nodo n0 set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 # Crea una fuente de tráfico CBR y lo asigna a udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetsize_ 500 $cbr0 set interval_ $cbr0 attach-agent $udp0 Estas líneas crean un agente UDP en el nodo n0, y se le añade un generador de tráfico CBR (constant bit rate) al agente UDP. Las líneas que siguen a las anteriores indican, cómo cabe intuir, una inicialización del tamaño del paquete de 500 bytes u octetos, y que cada paquete será enviado cada 5 ms, es decir, 200 paquetes por segundo. Las líneas de código que se muestran a continuación crean un agente Null que actúa como receptor en el nodo n1. set null0 [new Agent/Null] $ns attach-agent $n1 $null0 Ahora se deben conectar los agentes entre sí: $ns connect $udp0 $null0 Por último se debe indicar al agente CBR cuándo comenzar y parar de enviar datos. (Estas líneas deben ponerse antes de la línea que indica el final de la simulación: $ns at 5.0 "finish" ) $ns at 0.5 "$cbr0 start" $ns at 4.5 "$cbr0 stop" 9

10 Vamos a complicarlo un poco. Definición de topologías. Partiendo del código que se ha descrito anteriormente, que va ser común a todos los escenarios que implementemos, es decir, la creación de un objeto simulador, la ejecución de la simulación con el mismo comando, la apertura e inicialización de un fichero de traza, la creación de un procedimiento que cierra este fichero y ejecuta el Nam. Se pueden crear cuatro nodos mediante la inserción del siguiente nuevo código: set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] y se pueden crear conexiones entre ellas con el siguiente código: $ns duplex-link $n0 $n2 1Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 10ms DropTail $ns duplex-link $n3 $n2 1Mb 10ms DropTail Con estas líneas se expresa que los enlaces entre los nodos indicados son de tipo duplex, que el ancho de banda de la conexión es de 1Mb, con un retardo de 10ms y una cola del tipo DropTail. Si se desea tener un mayor control sobre la disposición de los nodos en la representación que hace Nam, se tiene la opción de introducir estas líneas de código, las cuales indican como se disponen los nodos atendiendo a sus conexiones: $ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns duplex-link-op $n2 $n3 orient right Nota: estas líneas son totalmente opcionales y sólo afectan a la presentación de los nodos, Nam también ofrece otros mecanismos para presentar disposiciones aleatorias de los nodos hasta encontrar una idónea. 10

11 2..10 LOS EVENTOS Ahora se crean dos agentes UDP, fuentes de tráfico CBR, y se asignan a los nodos n0 y n1; y un agente Null que se asigna al nodo n3. #Create a UDP agent and attach it to node n0 set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 # Create a CBR traffic source and attach it to udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetsize_ 500 $cbr0 set interval_ $cbr0 attach-agent $udp0 #Create a UDP agent and attach it to node n1 set udp1 [new Agent/UDP] $ns attach-agent $n1 $udp1 # Create a CBR traffic source and attach it to udp1 set cbr1 [new Application/Traffic/CBR] $cbr1 set packetsize_ 500 $cbr1 set interval_ $cbr1 attach-agent $udp1 set null0 [new Agent/Null] $ns attach-agent $n3 $null0 Los agentes que emiten el tráfico CBR deben estar conectados al agente Null encargado de recibirlo. $ns connect $udp0 $null0 $ns connect $udp1 $null0 El primer agente CBR enviará datos a partir del segundo 0,5 de la simulación, y parará en el segundo 4,5 mientras que el otro agente CBR comenzará en el segundo 1,0 y parará en el segundo 4,0. $ns at 0.5 "$cbr0 start" $ns at 1.0 "$cbr1 start" 11

12 $ns at 4.0 "$cbr1 stop" $ns at 4.5 "$cbr0 stop" Si se ejecuta el script con ns, se puede observar que el tráfico entre los nodos n0 y n2, y,n1 y n2 es mayor del que el enlace entre n2 y n3 puede soportar. Esto es porque estamos enviando 200 paquetes por segundo, cada uno de 500 bytes, en cada uno de los dos primeros enlaces; Esto supone un ancho de banda de 0.8 Mb/s por segundo para los enlaces entre n0 y n2, y, n1 y n2. Esto da como resultado un ancho de banda para el enlace entre n2 y n3 de 1.6 Mb/s pero hemos definido el ancho de banda de la conexión entre estos dos nodos de 1 Mb/s, luego el nodo n2 tiene que descartar algunos paquetes. Puede ser conveniente distinguir entre los paquetes enviados por un nodo u otro. Desde Nam existe la posibilidad de clicar en uno de los paquetes para ver su procedencia y su comportamiento. Otra forma es marcar los flujos de datos. Si se añaden estas líneas a la definición de los agentes CBR, $udp0 set class_ 1 $udp1 set class_ 2 y se incluyen estas otras líneas tras el objeto simulador, ya que serían parte de la inicialización del simulador: $ns color 1 Blue $ns color 2 Red se pueden ver los flujos representado con los colores rojo y azul MONITORIZACIÓN DE UNA COLA. Tan sólo hay que añadir la siguiente línea al código para monitorizar la cola en el enlace entre los nodos n2 y n3. $ns duplex-link-op $n2 $n3 queuepos 0.5 Ahora la ejecución de ns mostrará un esquema como el siguiente, donde se pueden ver los paquetes en la cola, e incluso cómo estos van siendo descartados: 12

13 2..12 CREACIÓN DE FICHEROS DE TRAZA PARA Xgraph. En este caso, hay que indicar en el script TCL, al igual que con nam, que se ejecute esta aplicación tomado unos ficheros de traza cuya información representará en unos gráficos. De la misma forma que hemos hecho con el fichero de traza de Nam, tenemos que: Definir y abrir los ficheros. set f0 [open xxx.tr w] set f1 [open yyy.tr w] Donde xxx.tr e yyy.tr son los nombres que reciben los ficheros en el sistema operativo. Cerrarlos y ejecutar Xgraph dentro del procedimiento finish. proc finish {} { global f0 f1 #Cierre de los ficheros de traza close $f0 close $f1 close $f2 #Ejecuta xgraph para mostrar las gráficas exec xgraph xxx.tr yyy.tr -geometry 800x400 & exit 0 } Si estamos utilizando al mismo tiempo Nam y Xgraph el procedimiento finish deberá cerrar también el fichero de traza de Nam y ejecutar Nam como ya hemos visto. Escribir los datos en los ficheros de traza. Para esto se utiliza un procedimiento llamado record : proc record {} { global tcp f0 f1 #obtenemos una instancia del simulador set ns [Simulator instance] #Indicamos el tiempo tras el cual se repite la ejecución (tiempo de muestreo) set time #Obtenmos los valores que se van a representar en la gráfica, en nuestro caso, la ventana de congestión y el sstresh set cwnd0 [$tcp set cwnd_] set ssthresh0 [$tcp set ssthresh_] 13

14 #obtenemos el tiempo del momento acutal set now [$ns now] #Escribimos en el fichero el par de valores (tiempo cwnd) puts $f0 "$now $cwnd0" #Escribimos en el fichero el par de valores (tiempo ssthresh) puts $f1 "$now $ssthresh0" #Ejecutamos nuevamente el procedimiento pasado el tiempo definido antes $ns at [expr $now+$time] "record" } Se han elegido los valores correspondientes a la ventana de congestión y al ssthresh porque son estos los valores sobre los que vamos a enfocar nuestros estudios para observar el comportamiento del protocolo TCP, pero se pueden utilizar otros valores como por ejemplo el número de bytes para almacenar en los ficheros de traza el ancho de banda de las diferentes conexiones. (ver ejemplo de 14

15 URG 3. ASPECTOS GENERALES DEL PROTOCOLO TCP TCP (Transmission Control Protocol) es un protocolo de transporte que implementa sus servicios sobre el protocolo de red IP. Esto significa que las tareas de control de flujo, corrección de errores, eliminación y secuenciamiento de datagramas IP, se hacen en este nivel con el fin de poder ofrecer un canal de flujo continuo a los procesos comunicantes. Tal vez TCP sea el protocolo más complejo e importante de la pila de protocolos. TCP presenta un servicio orientado a la conexión ofreciendo fiabilidad, a pesar de estar implementado sobre IP que es un protocolo de red no orientado a la conexión ni fiable. TCP aporta fiabilidad mediante el control de flujo, control de errores y control de congestión. Servicio Orientado a Conexión: La transmisión de datos de nivel de transporte presenta tres etapas: o establecimiento de la conexión o intercambio de datos o liberación de la conexión. Como peculiaridad, ambos extremos pueden transmitir y recibir datos simultáneamente. Los datos de la aplicación son troceados en segmentos del tamaño que TCP considera adecuado. Servicio Fiable: TCP es el primer nivel de la pila TCP/IP en el que se proporciona fiabilidad. Objetivo: Recuperar pérdidas y desórdenes producido por IP. Ideas principales: o Los segmentos con datos llevan un número de secuencia. o El receptor de los datos debe enviar asentimientos o confirmaciones (ACK). o Para cada segmento con datos transmitido se espera un plazo de tiempo a que llegue su asentimiento. Si vence el plazo, se retransmite el segmento. o Para asentimientos y retransmisiones se utiliza un protocolo de ventana. o El receptor reordena segmentos desordenados y descarta los duplicados. Los segmentos pueden llegar fuera de orden, puesto que debajo de TCP está IP (que es no orientado a la conexión, o sea, datagrama), y por tanto TCP debe reordenar los segmentos antes de pasarlos a la aplicación y sin duplicación alguna. La unidad de datos de TCP es el segmento, los cuales son encapsulados en datagramas IP. Estos segmentos de datos presentan una cabecera fija de 20 octetos que se muestra a continuación: Bit Puerto de origen Puerto de destino 20 octetos Desplaza- 6 bits reservados miento Número de secuencia Número de confirmación (ACK) Siguiente segmento esperado ACK RST PSH SYN FIN Tamaño de Ventana Suma de comprobación (CRC) Puntero a datos urgentes ~ Opciones + Relleno (0 o más palabras de 32 bits) 40 bytes máximo ~ ~ Datos de usuario ( = bytes como máximo) ~ 15

16 Como puede observarse, esta cabecera encaja muy bien con la cabecera IP. Seguidamente se explican los campos de la cabecera y los importantes mecanismos que implementa TCP para recuperación de información, control de flujo y control de congestión. Puerto origen y puerto destino (source port and destination port): Son números enteros de 16 bits cada uno (2 octetos), que designan el punto donde los procesos tienen acceso al servicio de comunicación TCP. La asignación del número de puerto al proceso iniciador de la comunicación es generalmente aleatoria, no así la del que responde (generalmente, otro proceso que habrá de prestarle un servicio). En TCP se han designado algunos puertos con número fijos bien conocidos (well-known ports), para los procesos que prestan ciertos servicios de uso habitual. Número de secuencia (sequence number): Marcando la diferencia entre un paquete IP y un segmento TCP, el número de secuencia de cuatro octetos, indica la posición, en el caudal de datos, del primer byte (octeto) perteneciente al segmento. El número no identifica al segmento, sino a una porción de aquel caudal ininterrumpido de bytes (stream), que fluye a través de una conexión TCP. Número de reconocimiento o acuse de recibo (acknowledgment number): El reconocimiento, de cuatro octetos tampoco identifica a un segmento particular. Se trata de un reconocimiento acumulativo. El número indica la posición en el stream del byte de menor número que el receptor aún no ha recibido (se supone que es igual al número de secuencia del siguiente byte a recibir). Obsérvese que el reconocimiento a un segmento puede enviarse en un segmento de datos, perteneciente a quien debe generar tal reconocimiento (piggybacking). Longitud de la cabecera (HLeng) Es un campo de cuatro bits que indica la cantidad de palabras de 4 octetos que se destinarán al campo opciones. Este número bien podría ser variable y con ello la cabecera igualmente, por lo tanto se hace necesario conocer su longitud. Debido a ello como máximo podrán ir destinadas 16 palabras de 4 octetos en este campo opciones. Espacio reservado (6bits) para futuros usos y mejoras del protocolo. Control o Code: Es un campo con 6 bits, utilizados como banderas, que permiten establecer el propósito y contenido del segmento y el cómo interpretar los otros campos del encabezado. Cada bit o bandera se puede interpretar con la siguiente tabla: Bit Significado: URG El campo apuntador urgente es válido. ACK El campo reconocimiento es válido PSH Este segmento debe enviarse solo. RST Reinicie conexión. SYN Sincronizar números de secuencia. FIN El emisor finaliza sus envíos Ventana (Window): Este campo es parte de otras de las funcionalidades de TCP: El control de flujo. TCP aprovecha el concepto de ventana deslizante, no solamente para aumentar el aprovechamiento del medio, sino también para permitir al receptor informar al emisor sobre su capacidad de 16

17 almacenamiento. Este campo del encabezado TCP indica el volumen de datos (bytes), que el receptor puede recibir para procesar. El emisor usa este valor para establecer el tamaño de su ventana de envío. Si en determinado momento el valor es cero, cuando el emisor reciba el segmento dejará de enviar datos. Checksum: Los checksums o sumas de verificación, son valores empleados para confirmar la integridad de los datos. El emisor calcula el checksum sobre los datos que enviará y lo incluye dentro del paquete. El receptor lo calcula nuevamente al recibir los datos y lo compara con el valor del emisor. Si son distintos es altamente probable que los datos hayan sido alterados durante la transmisión. Sin embargo, el checksum TCP (y también de UDP), es especial por cuanto en su cálculo no se considera solamente el segmento TCP. A este se le "agrega" (realmente no se le agrega, se considera para el checksum) un pseudo-encabezado que incluye las direcciones IP de las máquinas emisora y receptora. Puntero urgente (urgent pointer): TCP presta el servicio de envío de datos urgentes. Esto significa que el "cliente" de TCP puede solicitar que ciertos datos sean enviados tan rápido como sea posible. En tal caso, el emisor indica, con el bit URG del campo de control, que ese segmento contiene datos urgentes. Este campo (urgent pointer) señala la posición, en el cauce (stream), donde comienzan los datos urgentes. Opciones (options): Este campo es utilizado para el diálogo entre los dos módulos TCP. Se usa, por ejemplo, para establecer el tamaño máximo de segmento a intercambiar (maximum segment size). Este valor debe ser producto de una negociación que tome en cuenta el tamaño de los buffers, disponibles en cada extremo, y el desperdicio de ancho de banda con datos de control. 3.1 CONTROL DE FLUJO MEDIANTE MECANISMO DE VENTANA DESLIZANTE Algoritmo de Parada y espera Los protocolos de comunicación en general incorporan diversos algoritmos de confirmación de datos que pueden ser usados como control de flujo. Uno de los algoritmos de confirmación de datos es el conocido protocolo de parada y espera que garantiza un intercambio de datos seguro mediante un mecanismo de acuses de recibo. El algoritmo de parada y espera se basa en el envío desde el receptor al emisor de ACK por cada paquete recibido. El emisor deduce que el paquete ha sido recibido correctamente cuando recibe el ACK. Mientras el receptor realiza como única acción importante el envío del ACK por cada paquete recibido, el emisor del tráfico realiza las siguientes acciones: Almacena un registro de cada mensaje enviado. Activa el temporizador al envío del paquete. Espera el ACK Si ACK no llega antes de expirar el temporizador, reenvía el paquete. Si ACK llega, envía el siguiente paquete. 17

18 3.1.2 Mecanismo de Ventana deslizante La ineficiencia de algoritmos como el anterior causa que la mayor parte del tiempo la red no transporte datos sino ACK. Por ello TCP usa un mecanismo de ventana deslizante para: Garantizar la entrega fiable de datos. Garantizar que los datos serán entregados en orden. Forzar un control de flujo entre el emisor y el receptor. El control de flujo en el nivel de transporte es muy importante porque las velocidades a las que pueden llegar los datos al receptor son muy variables y de este modo el receptor puede comunicarle al emisor lo que está preparado para recibir. Se implementa mediante el uso de la ventana deslizante que permite cambiar el tamaño en el tiempo y que funciona según lo que se va a comentar en esta sección. Si pensamos en un control de flujo, función que deben realizar los protocolos de transporte, en el que el receptor indica el ritmo de envío del transmisor en función de sus recursos (buffer de recepción, capacidad de proceso, recursos de red, etc), podría funcionar si ambos, emisor y receptor están en la misma red, pero, qué es lo que pasa si el tráfico debe atravesar varias redes? Los routers normalmente no disponen de la capa TCP (como ya se ha mencionado TCP es un protocolo extremo a extremo, y los dos extremos son las aplicaciones que residen en los hosts). A la larga, el control de flujo tendría que acomodar el ritmo de envío a lo que permitiese la zona más congestionada, pero de todas formas siempre podrían perderse datagramas por diversos motivos. Tráfico excesivo Congestión RTO (1) sin recibir ACK Más tráfico Retransmisión (1) RTO: Round Trip Overtime. Tiempo en que se espera la recepción de la confirmación de un paquete (ACK) El emisor tiene un buffer en el que se van acumulando los segmentos que están preparados para enviar al receptor. Inicialmente envía la ventana de transmisión y, a medida que el receptor va devolviendo los ACK, los segmentos se van eliminando de la ventana de transmisión y se marcan como paquetes confirmados. Los que no están confirmados permanecen en la ventana de transmisión y la ventana deslizante no avanza. Este comportamiento puede observarse en la siguiente figura. Ventana de transmisión Buffer de transmisión Ventana de transmisión Bytes confirmados bytes enviados y a la espera de ACK por el receptor (paquetes on-flight) 18

19 El receptor dispone de un buffer que será el total de bytes que puede recibir. A medida que le van llegando segmentos irá enviando al emisor los ACK correspondientes y se irán señalando como ACK que se han enviado al emisor. El envío de ACK al emisor indica a éste el número de segmentos que puede seguir enviando sin que se desborde el buffer de recepción (ventana variable). La siguiente figura representa este funcionamiento. Ventana de recepción Buffer de recepción Ventana anunciada ACKs enviados al ACKs preparados para emisor enviar al emisor Se define un tamaño de ventana, que será el número de paquetes o cantidad de datos que se puede enviar sin esperar reconocimiento de ellos desde el receptor. Conforme se recibe el reconocimiento de los primeros paquetes transmitidos la ventana avanza de posición enviando los paquetes siguientes. Los ACK pueden recibirse en forma desordenada. Si el protocolo sólo contara con reconocimientos positivos gran parte de la capacidad de la red estaría desperdiciada, pues no se enviarían más paquetes hasta recibir el reconocimiento del último paquete enviado. El concepto de ventana deslizante permite que exista una continua transmisión de información, mejorando el rendimiento (throughput) de la red. El mecanismo de la ventana deslizante podría resumirse en los siguientes puntos: TCP ve el flujo de datos como una secuencia de bytes, la cual es dividida en segmentos para su transmisión. El mecanismo de ventana en TCP permite: 1. El envío de múltiples segmentos antes de que un reconocimiento sea recibido. El emisor envía un conjunto de bytes etiquetados con un numero de secuencia y espera que el receptor le responda con un único mensaje de confirmación. 2. Permite al receptor restringir la ventana de transmisión hasta que tenga suficiente espacio para recibir más datos. El receptor va indicando los mensajes que han sido recibidos y la ventana va pasando o deslizándose a los siguientes bytes a enviar a medida que los bytes son enviados correctamente. La ventana funciona y es vista como una secuencia de bytes y no como segmentos, mensajes o paquetes. Los bytes del flujo de datos están numerados secuencialmente. El emisor utiliza 3 apuntadores para definir la ventana: uno al principio, otro al final y otro en la posición de llenado actual. 19

20 El receptor cuenta con una ventana similar. En la siguiente figura podemos ver el mecanismo que incorpora TCP para el control de flujo y la recuperación de mensajes: Cuando se recibe un mensaje erróneo, éste será indicado al emisor que reenviará todos los paquetes a partir del anterior. En la figura se observa que si, por el contrario, se ha perdido un segmento, el emisor lo reenviará. En cuanto al mecanismo de reenvío hemos de destacar la existencia del temporizador de timeout que determina cuándo se ha perdido un paquete, al no recibir el emisor el ACK correspondiente al mensaje enviado. Del mismo modo, el receptor se encarga de mostrar esta pérdida al emisor mediante el envío de ACK duplicados. La variable timeout se usa para manejar la congestión. El temporizador es variable para poder adaptarse a las distintas condiciones que surgen en la red. Si el temporizador es demasiado corto se puede producir la confusión de entender como pérdida de paquetes la simple demora de éstos. Si el timeout es grande, se tardará demasiado en detectar las pérdidas y se desperdiciará el ancho de banda esperando ACK que no llegarán. Por ello el temporizador debe adaptarse a las condiciones de cada conexión. Se puede usar una estimación del RTT que se puede actualizar para cada ACK que llega. Esta estimación puede calcularse con la siguiente expresión: RTT=(α*RTT) + (1- α) * (RTT sample) Suele usarse un valor de α=7/8, para representar reacciones lentas a los cambios. Si se tiene una estimación del promedio de RTT se define un timeout igual al doble de ese valor promedio. Sin embargo, en situaciones de congestión elevada, la varianza de RTT aumenta considerablemente, llegando al doble del RTT medio. Para reflejar estas posibilidades TCP calcula también la desviación estándar del RTT y usa la varianza multiplicada por el RTT como timeout: DIFF=RTT sample-rtt RTT=RTT- α*diff MDEV=MDEV+ α*(abs(diff)-mdev) 20

21 3.2 CONTROL DE CONGESTIÓN DEL PROTOCOLO TCP TCP implementa un conjunto de algoritmos con los que proporciona una comunicación fiable extremo a extremo. Puede definirse congestión como la situación en la que el rendimiento de la red, o de una parte de ella, se degrada debido a la presencia de tráfico excesivo. El hecho de proporcionar una comunicación fiable entre dos hosts implica, entre otras cosas, que hay que encontrar la forma de controlar que los paquetes enviados lleguen al destino sin perderse en el camino; y si se pierden, proporcionar los medios necesarios para detectar la pérdida y volver a reenviarlos. Estas funciones son implementadas por los algoritmos de control de congestión y de recuperación de segmentos perdidos del protocolo TCP. Hay una diferencia importante entre congestión y control de flujo. El control de flujo suele hacerse en conexiones punto a punto, es decir, nivel de enlace o transporte. El control de congestión consiste en ejercer el control de flujo sobre los nodos que están produciendo la congestión. El control de congestión es un problema más complejo que el control de flujo pues el emisor del tráfico es un intermediario que lo más que puede hacer es reenviar el mensaje de control de congestión hacia atrás. Normalmente, cuando el mensaje llega al verdadero causante de la congestión el tráfico ya habrá cesado y será tarde para tomar medidas. El problema es aún mayor en redes de alta velocidad y gran retardo o gran distancia. Puede abordarse la congestión desde dos puntos de vista: Procurar que nunca se produzca la congestión. Tomar medidas para detectar la congestión y adoptar medidas correctoras en caso de producirse. Es necesario comprender que entre los factores del nivel de transporte que pueden influir en la congestión se pueden encontrarlos dos siguientes: El valor del intervalo de timeout o temporizador, ya que si es pequeño se generarán retransmisiones inncesarias. El tamaño de la ventana, ya que si es grande es más fácil que se produzca congestión, porque enviará más paquetes a la vez. Para resolver congestiones el descarte de paquetes debería ser el último recurso. Es habitual que los paquetes transporten indicación de su grado de importancia, en cuyo caso los routers intentarán descartar aquellos paquetes que lleven información menos relevante. Así es grave que para resolver congestiones se descarten paquetes de ACK. La capa de aplicación suele ser la que aporta la información sobre la prioridad de descarte del tráfico. En aplicaciones de tiempo real suele ser preferible descartar paquetes viejos a paquetes nuevos pues el viejo es inútil ya que su retransmisión provocará más problemas que ventajas. Sin embargo en las aplicaciones de transferencia de archivos el receptor necesita recibir todos los paquetes y el más antiguo generará la retransmisión por timeout. Además, hay que tener presente que en no pocos casos un paquete es parte de una secuencia correspondiente a otro paquete de mayor tamaño que fue fragmentado. En estos casos, si se descarta un paquete cualquiera de la secuencia del paquete originalmente fragmentado, tendrá que retransmitirse todo el grupo, por lo que al descartar uno de ellos es conveniente descartar todos los demás ya que son tráfico no válido que sobrecarga la red. Es necesario un mecanismo, llamado Control de congestión, encargado de disminuir el ritmo de envío a la red cuando ésta está próxima a la congestión. Pero, cómo saber en qué punto puede congestionarse algún punto de la red? Al inicio de la conexión el emisor desconoce el estado de la red; incluso no es seguro que ese estado sea constante durante una comunicación. La solución que propone TCP son los algoritmos Slow Start (que pone a prueba la capacidad de la red mediante el aumento progresivo del ritmo de envío de datagramas hasta detectar congestión) y Congestion Avoidance (que, una vez que se conoce la capacidad de la red, trata de 21

22 evitar llegar a la congestión de ésta). A estos dos clásicos algoritmos se unen también Fast retransmit y Fast recovery. Estos cuatro son los más significativos pero no los únicos y no todas las versiones de TCP los implementan todos. En cualquier caso tienen como principal cometido el lograr que TCP haga uso apropiado de los recursos de la red intentando solventar las posibles congestiones tal como se va a presentar a continuación. Hemos de destacar que la pérdida de segmentos causada por errores en los datos es mínima en la actualidad por el despliegue de la fibra óptica (con muy baja tasa de errores) y por la calidad de las infraestructuras en las redes actuales. Si hay pérdidas de segmentos es generalmente por congestión en alguna parte de la red. Un pérdida se detecta cuando se produce alguna de las situaciones siguientes: Ocurre timeout. Se reciben 3 ACK duplicados. 3.3 CÓMO SE CONTROLA LA CONGESTIÓN? La congestión aparece por una sobrecarga en los nodos de conmutación de la red, lo que provoca un incremento del retardo y retransmisiones que agravan la situación. TCP intenta solucionar la congestión reduciendo la inyección de segmentos en la red. El estándar actual recomienda dos técnicas relacionadas y fáciles de implementar que son los algoritmos Show Stara y Congestion avoidance. Antes de describir cómo funcionan estos algoritmos de TCP es necesario conocer algunos conceptos y definiciones [RFC 2581]: SEGMENTO. Se utiliza para designar cualquier paquete TCP/IP, ya sea un paquete de datos o uno de reconocimiento (ACK). RWND (Receiver Window). Indica la cantidad máxima de datos que puede recibir un receptor de trafico TCP. CWND (Congestion Window). Representa el valor de la ventana de congestión que es una variable que limita la cantidad de datos que TCP puede enviar (en ningún momento TCP podrá enviar segmentos con un número de secuencia mayor que la suma del ACK con mayor número de secuencia recibido y el menor de los tamaños de las variables rwnd y cwnd). El valor de cwnd variará dependiendo de las condiciones de la red. Si la red no descarta paquetes, el tamaño de la ventana aumentará, aumentando la velocidad de transmisión del emisor. SMSS (Sender Maximum Segment Size). Es el mayor tamaño de segmento que puede transmitir el emisor. La cantidad máxima de datos que el emisor puede enviar. RMSS (Receiver Maximum Segment Size). Es el mayor tamaño de segmento que el receptor puede admitir. La cantidad máxima de datos que el receptor puede recibir. IW (Initial Window). Valor inicial que toma la ventana de congestión. RTT (Round Trip Time). Tiempo que transcurre desde que el segmento ha sido enviado, hasta que se recibe la confirmación de que ha sido recibido por el receptor. El RTT determina la velocidad de transmisión de TCP, ya que el emisor TCP envía cada RTT el tamaño determinado por cwnd. CURRENT WINDOW. Representa la cantidad de información que envía el emisor cada RTT. Esta variable toma el valor más pequeño de entre cwnd y rmss. SSTHRESH. Esta variable se utiliza para determinar qué mecanismo de control de congestión, Slow Start o Congestion Avoidance se debe aplicar en cada instante y según el siguiente algoritmo: Si cwnd ssthresh Aplica algoritmo Slow Start 22

23 Si cwnd > ssthresh Aplicar algoritmo Congestion Avoidance Algoritmo Slow Start El protocolo TCP está diseñado para controlar el envío y recepción de segmentos TCP a fin de evitar momentos de congestión en la red. Inicialmente, y desde las primeras versiones de TCP, se realizaban las comunicaciones con el destino enviando segmentos TCP de manera continuada y sin hacer control alguno, prevaleciendo únicamente el tamaño de la ventana que imponía el receptor. Esta técnica de desplazamiento de ventana es una técnica de control del flujo impuesta por el receptor de segmentos TCP con el fin de evitar momentos de congestión en el computador receptor. Durante el proceso de inicialización de una conexión TCP, el proceso TCP de cada computador da a conocer los parámetros de control ventana y máximo tamaño de segmento. Con estos dos parámetros, el proceso de envío de segmentos del protocolo TCP puede calcular el máximo número de segmentos que puede recibir el proceso de recepción del protocolo TCP en un momento determinado. El parámetro ventana, incluido en una cabecera TCP, es un registro de 16 bits y el valor del mismo puede variar durante el envío y recepción de segmentos TCP hasta llegar al punto de que sea igual a cero. Cuando esto ocurre indica que el proceso de recepción de segmentos no está en capacidad de recibir ningún segmento TCP ya que el buffer de recepción se encuentra completamente lleno. Esto obliga al proceso de envío de segmentos TCP del computador remoto a no transmitir ningún segmento hasta que el parámetro de control ventana sea mayor o igual a un segmento. Por tanto, el emisor maneja dos tamaños para la ventana: el de congestión y el que informa el receptor. El tamaño usado es siempre el menor de ambos valores. La ventana de congestión parte con tamaño 1, y sólo al recibir los ACK aumenta su valor. Esta técnica de desplazamiento o deslizamiento de ventana funciona si la conexión TCP se establece en una red local, pero cuando la conexión TCP se establece a través de una red WAN los enrutadores pueden experimentar momentos de congestión ya que los mismos interactúan con un servicio de conexión no orientado y la capacidad de envío y recepción de datos de un enlace WAN en la mayoría de los casos es mucho menor que el de una red LAN. Para resolver este inconveniente el protocolo TCP hace uso de la técnica de comienzo lento (aunque no es precisamente lento ya que el ritmo de envío del tráfico es exponencial) Slow Start, cuya finalidad es consultar y detectar el estado de la red y adecuar el flujo TCP en consecuencia. Intenta evitar que una nueva conexión intente transferir desde el inicio demasiados datos a una red congestionada. La idea por tanto consiste en que la nueva conexión empiece a transmitir despacio aumentando su tasa de transferencia gradualmente según las condiciones de la red. Para ello se define una nueva variable, la ventana de congestión cwnd, que limitará la cantidad de segmentos que el emisor podrá enviar al receptor para no inundar la red o no inundar al receptor y, en consecuencia, no provocar una situación de congestión. De esta forma, el emisor y el receptor negocian para ello un valor inicial de ventana, que suele tomar valor 1. El emisor colocará segmentos en la red a la velocidad a la que reciba los ACK s desde el otro extremo (receptor), de manera que sólo al recibir ACK s se incrementará el tamaño de cwnd. Este cwnd provocará que en la siguiente retransmisión generalmente se realice con el doble de tamaño y así sucesivamente. La forma en que se detecta o averigua la capacidad de la red es bastante simple: si se comienzan a descartar paquetes se asume que el tamaño era más grande que la capacidad de la red. Durante el establecimiento de la conexión, el otro extremo indica su ventana de recepción. Se calcula el tamaño de una segunda ventana de congestión con el propósito de moderar la transmisión de acuerdo con las condiciones de la red. Por lo tanto, el emisor quedará limitado por la ventana de congestión en lugar de por la ventana de recepción (que es mayor). La ventana de congestión comienza con un segmento (valor inicial de CWND=1). A partir de ahí por cada segmento del que recibe un ACK correctamente, aumenta en un segmento la 23

24 ventana de congestión, mientras sea menor que la de recepción. Si la red no se encuentra sobrecargada, la ventana de congestión alcanza pronto el tamaño de la ventana de recepción. La ventana crece a su tamaño natural exponencialmente: Tras el primer ACK, la ventana de congestión es de 2 segmentos. Al llegar un ACK para 2 segmentos, la ventana se incrementa para 4 segmentos. Si llega otra confirmación para estos 4, la ventana se incrementa a 8 y así sucesivamente. Es decir, el emisor colocará segmentos en la red a la velocidad a la que reciba los ACK desde el otro extremo. Sólo al recibir ACK se incrementará (el doble) el tamaño de CWND, tal como se representa en la siguiente figura. Como podemos observar y, aunque por lo general no se comporta como una progresión cuadrática, podemos aproximar el tamaño de la ventana de congestión cwnd en cada retransmisión de la siguiente manera: CWND (t + 1) = CWND (t) * 2 ; O lo que es lo mismo: CWND (t) = CWND (t-1) * 2 ; En la gráfica anterior podemos observar cómo el número de segmentos enviados cada RTT usando la ventana CWND crece de forma exponencial. En la siguiente gráfica podemos ver cómo aumenta el número de segmentos enviados en cada RTT: 24

25 De esta manera, como hemos explicado anteriormente, el aumento de tamaño de la ventana de congestión cwnd depende de los ACK s que se vayan recibiendo desde el receptor, por lo que igualmente se está dependiendo de la congestión que pudiera existir o no en la red. Por tanto, podemos decir que a mayor congestión, menos ACK s recibidos y, por consiguiente, la ventana de congestión cwnd será más pequeña y retransmitirá menos segmentos TCP en ese instante de tiempo. Vemos como el algoritmo Show Stara es un mecanismo útil de control de congestión: A mayor congestión, menos ACK recibidos, lo que implica que el tamaño de CWND será más pequeño y por lo tanto se transmitirán menos segmentos en ese momento. La primera transmisión será de 1 segmento (*) de tamaño máximo igual al anunciado por el receptor (RMSS). Valor inicial de cwnd (IW): 1 segmento (en realidad 1 * MSS bytes). Cuando recibe el ACK correspondiente, cwnd se incrementa para permitir 2 segmentos (cwnd=2*mss) (1+1). Si la ventana ofrecida (rwnd) es mayor o igual, el transmisor envía 2 segmentos. (*) Definición original de Slow start: IW=1 segmento; Versión actual RFC 2581 (1999) IW 2 x MSS; IW 2 segmentos. por qué utilizar IW > 1? Política 1 ACK cada 2 segmentos. RTT muy grande (ejemplo: enlace satélite). Cada vez que recibe un ACK, el emisor incrementa en uno el número de segmentos transmitidos (incrementa el tamaño de la ventana de congestión). De esta forma, la primera vez se envía un segmento; al recibir su ACK correspondiente se aumenta en uno cwnd y se envían ahora dos segmentos de los que se espera recibir dos ACK; luego, al recibirlos, cwnd se incrementará en dos y en el próximo envío transmitirá 4 segmentos de los que espera recibir los correspondientes 4 ACK. Esta situación se mantiene mientras el valor de cwnd sea: Menor que rwnd, Menor que ssthresh y no exista congestión. A pesar del nombre del algoritmo, estamos por tanto frente a un incremento exponencial (cwnd se va duplicando) de la ventana de congestión al inicio. En ausencia de congestión se alcanza la ventana máxima (=rwnd) en aproximadamente RTT * log 2 (rwnd) segundos. Slow Start hace oscilar la ventana de congestión en torno a su valor ideal. Así se ajusta la velocidad a la que se deben transmitir los datos. Su principal problema es su agresividad ya que no se reduce el tamaño de la ventana hasta que se produce una pérdida de paquete. Por ello TCP se combina con otros algoritmos que veremos a continuación Algoritmo Congestion Avoidance En este algoritmo se hace la suposición que la probabilidad de pérdida de un paquete en la red por error en un enlace es nula, por tanto, si un paquete no llega es porque ha habido congestión en alguna parte de la red, no porque haya habido errores. Como sabemos, la congestión en la red se produce cuando se intenta enviar una gran cantidad de segmentos en una red lenta o bien cuando estos envíos intentan atravesar un router cuya capacidad de almacenamiento es menor que estos segmentos de entrada. Por lo general, y 25