Protocolos de La Capa de Transporte

Protocolos de transporte
Jos M. Barcel Ordinas Jordi igo Griera

P07/89013/00291
FUOC P07/89013/00291
FUOC P07/89013/00291
ndice
Introduccin ............................................................................................ Objetivos ................................................................................................... 1. Protocolos del nivel de transporte ............................................... 2. El UDP (user datagram protocol) ...................................................
5 6 7 9
3. El TCP (transmission control protocol) ........................................ 11 3.1. El TCP proporciona fiabilidad ........................................................ 11 3.2. Formato del segmento TCP ............................................................ 12 3.3. MSS ................................................................................................. 17 3.4. Establecimiento de la conexin ..................................................... 17 3.5. Terminacin de la conexin ........................................................... 20 3.6. Diagrama de estados del TCP ......................................................... 22 3.7. Transferencia de la informacin ..................................................... 24 3.7.1. Transmisin de datos interactivos ...................................... 25 3.7.2. Transmisin de datos de gran volumen. Control de flujo por ventana deslizante ............................. 26 3.7.3. Temporizadores y retransmisiones ..................................... 30 Resumen .................................................................................................... 36 Ejercicios de autoevaluacin ............................................................... 37 Solucionario ............................................................................................. 38 Glosario ..................................................................................................... 39 Bibliografa .............................................................................................. 40 Anexos ....................................................................................................... 41
FUOC P07/89013/00291
FUOC P07/89013/00291
Introduccin
La red Internet utiliza el protocolo IP para que las estaciones se enven paquetes. Este protocolo es no orientado a conexin, o sea que no se preocupa de hacer llegar bien los paquetes, ni que lleguen en orden. De hecho, no garantiza ni siquiera que lleguen. De todo eso se encargan los protocolos de transporte. Una de las razones de esta divisin del trabajo es que los protocolos de transporte slo se tienen que aplicar a las estaciones terminales, de manera que el control de la transmisin se efecta de extremo a extremo. En Internet se definieron bsicamente dos protocolos de transporte: UDP y TCP. UDP slo garantiza la entrega libre de errores. No preserva la secuencia ni garantiza la entrega, mientras que TCP s que preserva la orden en la que han sido transmitidos los paquetes y garantiza su entrega. Veremos en este mdulo cmo funcionan estos dos protocolos de transporte, y para qu tipo de aplicaciones son tiles el uno y el otro.
FUOC P07/89013/00291
Objetivos
En este mdulo didctico, encontraris los recursos necesarios para lograr los objetivos siguientes: 1. Saber en qu principios se basan los protocolos de control de la transmisin punto a punto (TCP y UDP). 2. Conocer las caractersticas de UDP y los usos que puede tener. 3. Conocer las caractersticas de TCP y los usos que puede tener. 4. Conocer algunas utilidades de uso comn que permiten investigar empricamente las interioridades de la red.
FUOC P07/89013/00291
1. Protocolos del nivel de transporte
Las aplicaciones utilizan la red para que la informacin viaje entre los dos extremos de la comunicacin. Pero si la red no puede proporcionar una conexin fiable, hace falta alguien que lo haga. Por eso existe el nivel de transporte.
Entendemos por conexin fiable que todos los paquetes lleguen, y lleguen en orden. Pero eso tiene un coste, sobre todo en tiempo, porque si un paquete no llega, habr que pedir la retransmisin, y esperar que llegue bien. Como veremos ms adelante, hay aplicaciones en las que este retraso (que adems es variable, ya que la situacin no siempre tiene que darse igual) puede no ser deseable. Entonces es necesario que el nivel de transporte ofrezca diferentes niveles de fiabilidad, y dejar que las aplicaciones escojan.
Recordamos... ... que los paquetes de una misma comunicacin pueden seguir diferentes caminos por la red y, por lo tanto, pueden utilizar diferentes tiempos en atravesarla y llegar desordenados.
En el caso de TCP/IP eso se consigue teniendo dos protocolos: uno que proporciona la fiabilidad completa (los paquetes llegan bien y en orden), y otro que slo proporciona un simple control de errores. El primero es el TCP (transmission control protocol) y el segundo es el UDP (user datagram protocol).
Se dice que TCP es un protocolo orientado a conexin, mientras que UDP es no orientado a conexin.
La figura siguiente ilustra la situacin de los protocolos de transporte en la pila TCP/IP.
FUOC P07/89013/00291
Otra funcin importante que proporcionan los protocolos de transporte es la de identificar las aplicaciones que transportan.
EN TCP/IP la comunicacin se establece entre aplicaciones, no slo entre mquinas. Por lo tanto, para comunicarnos con una aplicacin remota necesitamos saber no slo la direccin IP de la mquina, sino tambin el nmero de aplicacin. Este nmero se conoce como puerto.
Pero el puerto se define a nivel de transporte, no a nivel de aplicacin. Por eso, aparecer en la cabecera de TCP (o UDP), de la misma manera que en la cabecera de IP aparece un identificador relacionado con el protocolo de transporte que hay en aquel paquete. Este identificador de puerto es de 16 bits, por lo tanto, se pueden definir hasta 65.536 aplicaciones diferentes en Internet. Cuando se especificaron las primeras aplicaciones, pareci conveniente darles un puerto concreto y se decidi que los primeros 1.024 puertos de los 65.536 posibles se reservaran a aplicaciones muy conocidas, y se conoceran as como puertos bien conocidos (well-known ports).
Ejemplo Algunos de los puertos conocidos son: Puerto 7 para el servidor de eco Puertos 20 y 21 para el protocolo de transferencia de ficheros Puerto 53 para el servidor de nombres Puerto 80 para el HTTP
Los puertos conocidos son asignados por la IANA (Internet Assigned Numbers Authority).
As, un punto de conexin a nivel de aplicacin se identifica con la pareja direccin IP/puerto.
FUOC P07/89013/00291
2. El UDP (user datagram protocol)
El UDP es un protocolo no orientado a la conexin, de manera que no proporciona ningn tipo de control de errores ni de flujo, aunque utiliza mecanismos de deteccin de errores. En caso de detectar un error, el UDP no entrega el datagrama a la aplicacin, sino que lo descarta.
Protocolo no orientado a comunicacin
Conviene recordar que, por debajo suyo, el UDP est utilizando el IP, que tambin es un protocolo no orientado a la conexin. Por tanto, se pens en definir un protocolo del nivel de transporte que permitiera que la aplicacin explotara este tipo de caractersticas y que fuera cuanto ms simple y sencillo mejor. La simplicidad del UDP hace que sea ideal para aplicaciones que requieren pocos retrasos (por ejemplo, aplicaciones en tiempo real). El UDP tambin es ideal para los sistemas que no pueden implementar un sistema tan complejo como el TCP. Otro uso interesante del UDP es en aplicaciones que trabajan en modo multicast o broadcast (enviar informacin a un grupo de usuarios o a todos los usuarios de la red). En este caso, se enva informacin a muchos receptores sin esperar una respuesta de todos, de manera que es ideal disponer de un protocolo de transporte simple y sencillo no orientado a la conexin como el UDP. Las caractersticas ms importantes del UDP son las siguientes: No garantiza la fiabilidad; es decir, no se tiene la seguridad de que cada datagrama UDP transmitido llegue a su destino; es un protocolo best-effort: el UDP hace todo lo posible para transferir los datagramas de su aplicacin, pero no garantiza su entrega. No preserva la secuencia de la informacin que le proporciona la aplicacin. Como est en modo datagrama y utiliza un protocolo por debajo como el IP, que tambin est en modo datagrama, la aplicacin puede recibir la informacin desordenada. La aplicacin debe estar preparada para que haya datagramas que se pierdan, lleguen con retraso o se hayan desordenado. La figura siguiente muestra la unidad de datos del protocolo UDP y su encapsulamiento en un datagrama IP. Cada operacin de salida de un datagrama UDP provoca la generacin de un datagrama IP:
El UDP es un protocolo no orientado a la conexin. Ello significa que cada datagrama UDP existe con independencia del resto de los datagramas UDP.
FUOC P07/89013/00291
10
El datagrama UDP consta de una cabecera y un cuerpo para encapsular los datos. La cabecera consta de los elementos siguientes: Los campos Puerto de origen y Puerto de destino, que identifican las aplicaciones en los terminales de origen y de destino. Cada puerto tiene 16 bits. El campo Longitud indica la longitud, en octetos, del datagrama UDP incluyendo la cabecera UDP (es la diferencia de la longitud del datagrama IP menos la cabecera IP). Como la longitud mxima de un datagrama IP es de 65.535 bytes, con una cabecera estndar de 20 bytes, la longitud mxima de un datagrama UDP es de 65.515 bytes. El campo Checksum (16 bits) es opcional y protege tanto la cabecera como los datos UDP (es preciso recordar que el checksum del datagrama IP slo cubre la cabecera IP). Cuando el UDP recibe un datagrama y determina que hay errores, lo descarta y no lo entrega a ninguna aplicacin.
Clculo del checksum en el UDP El clculo del checksum en el UDP es muy parecido al clculo del checksum en el IP (suma en complemento en unos de palabras de 16 bits), con la particularidad de que la longitud del datagrama UDP puede ser par o impar. En caso de que sea impar, se le aade un 0 al final del datagrama para calcular el checksum (este 0 no se transmite). Para calcular el checksum, el UDP utiliza una seudocabecera de 12 bytes con algunos de los campos IP. Esta ltima no se transmite; el UDP slo la utiliza para calcular el checksum y le sirve para comprobar que la informacin que le proporciona el IP sea realmente para l. Medida de los buffers de las aplicaciones Hay muchas aplicaciones que limitan la medida de sus buffers de transmisin y recepcin por debajo de la medida mxima de un datagrama UDP. Por ejemplo, es tpico encontrar aplicaciones que proporcionan, por defecto, medidas mximas del datagrama UDP de 8.192 bytes. Este valor proviene de la cantidad de datos del usuario que el NFS (network file system) puede leer o escribir por defecto.
FUOC P07/89013/00291
11
3. El TCP (transmission control protocol)
Como hemos podido observar, el UDP no garantiza la entrega de la informacin que le proporciona una aplicacin. Tampoco reordena la informacin en caso de que llegue en un orden diferente de aqul en que se ha transmitido. Existen aplicaciones que no pueden tolerar dichas limitaciones. Para superarlas, el nivel de transporte proporciona un protocolo llamado TCP. El TCP proporciona fiabilidad a la aplicacin; es decir, garantiza la entrega de toda la informacin en el mismo orden en que ha sido transmitida por la aplicacin de origen. Para conseguir esta fiabilidad, el TCP proporciona un servicio orientado a la conexin con un control de flujo y errores.
3.1. El TCP proporciona fiabilidad Para proporcionar un servicio fiable a la aplicacin, el TCP se basa en los principios siguientes: 1) Transmisin libre de error. El TCP debe entregar a la aplicacin de destino exactamente la misma informacin que le entreg la aplicacin de origen. De hecho, se trata de una entrega casi libre de errores, puesto que puede haber algunos que un mecanismo de deteccin de errores no pueda detectar. 2) Garanta de entrega de la informacin. El TCP garantiza que toda la informacin transmitida por la aplicacin de origen se entregue a la aplicacin de destino. Si no es posible, el TCP debe avisar a la aplicacin. 3) Garanta de mantenimiento de la secuencia de transmisin. El TCP garantiza la entrega del flujo de informacin en el mismo orden en que le fue entregado por la aplicacin de origen. 4) Eliminacin de duplicados. El TCP garantiza que slo entregar una copia de la informacin transmitida a la aplicacin de destino. En caso de que reciba copias a causa del funcionamiento de la red o de los protocolos que se implementan por debajo del nivel de transporte, el TCP las eliminar. Las propiedades siguientes del TCP garantizan un servicio de entrega fiable de la informacin: a) El TCP define flujos (stream oriented): la aplicacin organiza los datos de informacin en flujos (streams) de bits estructurados en bytes. En consecuencia, el receptor pasa a su aplicacin el mismo flujo de bytes que la aplicacin de origen ha pasado al TCP. Por otro lado, la aplicacin no tiene ningn modo
FUOC P07/89013/00291
12
de indicar al TCP los lmites en que quiere transferir la informacin: es el TCP el que decide en cada momento cuntos bytes transfiere en un segmento. b) El TCP est orientado a la conexin: tiene una fase de establecimiento de la conexin, una de transmisin de datos y una de desconexin. c) El TCP utiliza el concepto buffered transfer: cuando se transfiere informacin, el TCP divide los flujos de datos (bytes) que le pasa la aplicacin en trozos del tamao que le convenga. El TCP decide el tamao de los segmentos tanto si la aplicacin genera un byte de informacin, como si genera flujos de gran dimensin. En el primer caso, el TCP puede esperar que la memoria intermedia est ms llena antes de transferir la informacin, o bien la puede transferir de inmediato (mecanismo push). En caso de que los flujos sean muy grandes, el TCP puede dividir la informacin en tamaos ms pequeos antes de transferirlos. d)El TCP utiliza una conexin full duplex: la transferencia de informacin es en ambos sentidos. La aplicacin ve dos flujos independientes. En caso de que la aplicacin cierre uno de los flujos, la conexin pasa a ser half duplex. Ello significa que uno de los extremos (el que no ha cerrado la conexin) puede continuar enviando informacin por el canal, mientras que el otro extremo (el que ha cerrado la conexin) se limita a reconocer la informacin. No obstante, no es normal encontrar este caso. Lo ms habitual es que, si un extremo cierra la conexin, el otro tambin la cierre.
3.2. Formato del segmento TCP La unidad de informacin del protocolo TCP se llama segmento TCP y su formato el siguiente:
FUOC P07/89013/00291
13
El segmento TCP consta de una cabecera y un cuerpo para encapsular datos. La cabecera consta de los campos siguientes:
a) El campo Puerto de origen identifica la aplicacin en el terminal de origen.
b) El campo Puerto de destino identifica la aplicacin en el terminal de destino.
c) El campo Nmero de secuencia identifica el primer byte del campo de datos. En el TCP no se numeran segmentos, sino bytes. Por tanto, el nmero de secuencia identifica el primer byte de los datos que enva el segmento: al principio de la conexin se asigna un nmero de secuencia inicial (ISN, del ingls initial sequence number), a partir del cual el TCP numera los bytes consecutivamente.
d) El campo Nmero ACK. El TCP reconoce datos por medio de la tcnica de piggybacking. Al activar un bit de la cabecera (el bit ACK), el TCP tiene en cuenta el nmero de secuencia ACK que indica al otro extremo TCP el prximo
FUOC P07/89013/00291
14
byte que est dispuesto a recibir. Dicho de otra manera, el nmero ACK menos uno indica el ltimo byte reconocido.
e) El campo Longitud de la cabecera indica la longitud de la cabecera, que puede ser variable. La longitud tpica es de 20 bytes; sin embargo, si el TCP utiliza el campo de opciones, puede llegar a una longitud mxima de 60 bytes. De este modo, el TCP sabe dnde empiezan los datos.
f) El campo Reservado, tal como su nombre indica, est reservado y se inicializa con ceros.
g) El campo Control est formado por ocho indicadores independientes, cada uno de los cuales seala una funcin especfica del protocolo cuando est activo (a 1):
FUOC P07/89013/00291
15
FIN: indica que el transmisor ha acabado la conexin.
SYN: se utiliza para iniciar una conexin y tambin sirve para resincronizar los nmeros de secuencia.
RST: realiza un reset de la conexin.
PSH: invoca la funcin push en el protocolo. Esta funcin dice al receptor que entregue a la aplicacin todos los datos que tenga disponibles en la memoria intermedia de recepcin sin esperar a completarlos con datos adicionales. De este modo, los datos no esperan en la memoria intermedia receptora hasta completar un segmento de dimensin mxima.
Atencin No debe confundirse con el indicador URG, que indica que la aplicacin ha sealado una porcin del segmento como urgente.
ACK: cuando este bit est activo, el campo Nmero ACK indica el byte siguiente que espera recibir la conexin TCP. Si este bit no est activo, el campo Nmero ACK no tiene ningn significado para el TCP.
URG: indica que hay datos urgentes (y el campo Urgent pointer indica la cantidad de datos urgentes existentes en el segmento).
ECE
CWR: estos dos bits se utilizan si se implementa un control de congestin.
Control de congestin En el ao 1999, en el RFC 2481, se hizo una propuesta de tcnica de control de congestin con notificaciones explcitas, que necesita estos dos bits (ECE y CWR) que no existan en la versin inicial de TCP.
h) El campo Ventana indica cuntos bytes componen la ventana de transmisin del protocolo de control de flujo por ventana deslizante. A diferencia de los protocolos del nivel de enlace, en que la ventana era constante y contaba tramas, en el TCP la ventana es variable y cuenta bytes. Con cada segmento transmitido, un extremo TCP advierte al otro extremo de la cantidad de datos que est dispuesto a recibir en cada momento. De este modo, el extremo que recibe un segmento actualiza el tamao de su ventana de transmisin.
FUOC P07/89013/00291
16
i) El campo Checksum se utiliza para detectar errores.
j) El campo Urgent pointer tiene sentido cuando el bit de control URG est activo, indica que los datos que enva el origen son urgentes e identifica el ltimo byte del campo de datos que tambin lo es. El receptor procesa estos datos lo ms rpido posible. La aplicacin es la que indica que estos ltimos son urgentes y lo sabe porque el TCP se lo indica en la recepcin.
Por ejemplo,... ... si el nmero de secuencia indica 1.000 y el urgent pointer indica 200, significa que los bytes del 1.000 al 1.200 se consideran urgentes. A partir del byte 1.201 los datos se vuelven a considerar normales.
Agunas aplicaciones que utilizan el urgent pointer son, por ejemplo telnet, rlogin o ftp. En la librera de sockets, el trfico urgente se denomina trfico fuera de banda (out of band).
En el mdulo Aplicaciones Internet de esta asignatura, podis ver ejemplos de cmo se utilizan las aplicaciones telnet, rlogin y ftp.
k) El campo Opciones TCP permite aadir campos a la cabecera para realizar las operaciones siguientes:
Marcar el tiempo (timestamp) en que se transmiti el segmento y de este modo poder monitorizar los retrasos que experimentan los segmentos desde el origen hasta el destino. Aumentar el tamao de la ventana. Indicar el tamao mximo del segmento (MSS) que el origen est preparado para recibir.
FUOC P07/89013/00291
17
3.3. MSS En principio, no hay ninguna restriccin especial para la medida de los segmentos TCP. Se puede pensar que cuanto mayores sean, mejor, porque se amortizan ms las cabeceras. No obstante, recordamos que para que el segmento llegue a su destino tendr que pasar por redes que utilizan niveles de enlace que fijan una MTU. O sea, si un paquete IP grande (porque contiene un segmento grande) llega a una red con una MTU pequea, tendr que ser fragmentado. La fragmentacin no es ningn problema, pero si se puede evitar, mejor. Cada extremo TCP conoce la red donde est, y sus caractersticas. As, en el establecimiento de la conexin, el TCP anuncia a su interlocutor la medida mxima que tiene que tener un segmento dirigido hacia l para que no se produzca fragmentacin. Esta cantidad se conoce como MSS.* En caso de que durante el establecimiento de conexin no se reciba un valor de MSS, se utiliza un valor por defecto de 536. MSS slo se refiere al segmento. Si la MTU de una red es de 1.500 bytes, entonces MSS vale 1.460, porque le restamos los 20 bytes de la cabecera IP y los 20 de la cabecera TCP. Por lo tanto, para ser exactos, MSS es la medida mxima de los datos de un segmento que un TCP est dispuesto a recibir. En algunos textos se habla de negociacin del MSS. Eso no es del todo cierto, porque los dos extremos TCP no negocian nada. Cada uno anuncia al otro su MSS, y no se discute, y pueden ser dos valores diferentes si estn en redes de diferente MTU. Este intercambio de valores de MSS no garantiza que no haya fragmentacin, porque se puede dar el caso de que el paquete tenga que atravesar una red que tiene una MTU inferior a las dos de las redes donde estn los extremos. Para evitar esto, existe un mecanismo, denominado MTU discovery path, que se puede aplicar antes del intercambio inicial de valores de MSS y sirve para averiguar la MTU ms pequea que se atravesar.
Se consideran las cabeceras mnimas... ... de 20 bytes porque cuando se llenan los paquetes es en transmisiones de datos, y en estos casos no se suelen poner opciones en las cabeceras. Utilizar los campos de opciones ocurre normalmente en el establecimiento de la conexin, y en este caso, los paquetes no van llenos.
* MSS es la sigla de maximum segment size.
3.4. Establecimiento de la conexin Para establecer una conexin, el TCP utiliza el protocolo three-way handshake. Este ltimo necesita tres segmentos TCP para poder establecer la conexin. Consideremos que el servidor est en un estado de escucha, llamado listen, y que el cliente quiere establecer una conexin con el servidor. El TCP de la mquina cliente iniciar la peticin de conexin TCP, que ser contestada por el TCP de la mquina servidor.
FUOC P07/89013/00291
18
Para que el cliente TCP pueda establecer una conexin TCP con el servidor, se siguen los pasos siguientes: 1) Peticin de la conexin El TCP cliente enva un segmento de peticin de conexin al servidor. Dicho segmento, que se conoce como segmento SYN porque tiene activado el bit SYN en el campo Control de la cabecera del segmento TCP, especifica el nmero de secuencia inicial TCP del cliente (ISN). El nmero de secuencia inicial se elige al azar. La razn es muy sencilla. Hay paquetes que pueden sobrevivir en la red una vez se ha cerrado la conexin TCP (incluso si ha sido a causa de una cada del sistema). Es preciso asegurarse de que una conexin nueva elige un nmero de secuencia inicial que no exista. El TCP recomienda utilizar un nmero de secuencia inicial basado en una variable que se incrementa una cantidad x cada y tiempo (por ejemplo, en 4.4BSD hay un contador que se incrementa cada 8 ms). Si el sistema cae, pasados unos segundos vuelve a estar en funcionamiento e inmediatamente se establece una conexin nueva utilizando el mismo puerto y la misma direccin IP, se podra interpretar que los segmentos TCP que han quedado retrasados en la red y que ya existan con anterioridad a la cada de la mquina, pertenecen a la conexin nueva, lo que provocara la confusin y el mal funcionamiento de dicha conexin. Ello sucedera incluso con independencia del nmero de secuencia inicial elegido. Con el objetivo de protegerse de esta situacin, se combinan dos tcnicas: una consiste en elegir el nmero de secuencia inicial de manera aleatoria y la otra es el denominado quiet time, que consiste en que el TCP no crea ninguna conexin nueva despus de un rebote de mquinas hasta que no transcurre un tiempo determinado denominado MSL* o tiempo mximo de vida de un segmento. De este modo, se asegura de que no recibir segmentos antiguos de otras conexiones.
* MSL es la sigla de maximum segment lifetime.
Segmento SYN Este segmento especifica ms parmetros, tales como el puerto del servidor al que se quiere conectar el cliente, y suele especificar tambin la medida mxima del segmento (MSS) que el cliente transmitir.
FUOC P07/89013/00291
19
El MSL depende de la implementacin; sin embargo, los valores normales son, aproximadamente, de 30 segundos, 1 minuto 2 minutos. No obstante, existen muchas implementaciones que no tienen en cuenta esta situacin, puesto que consideran que un rebote de mquinas dura ms tiempo que el MSL.
2) Confirmacin de la conexin El servidor responde a la peticin de establecimiento de la conexin con un segmento SYN que indica el nmero de secuencia inicial que utilizar. Asimismo, este segmento contiene un reconocimiento (ACK) del segmento SYN del cliente que indica el ISN del cliente ms 1 (el nmero de secuencia inicial del cliente ms 1).
Conviene recordar que el TCP numera los ACK con el nmero de secuencia del prximo byte que espera recibir (en este caso, el servidor espera que el prximo byte enviado por el cliente sea J + 1). En la figura anterior, sera el segmento SYN (K), ACK ( J + 1), donde K es el ISN elegido por el TCP servidor.
3) Reconocimiento de la conexin El cliente reconoce el segmento SYN (K) del servidor con un reconocimiento que contiene el ISN servidor ms 1. En la figura anterior, sera el segmento ACK (K + 1). Se dice que quien enva el primer segmento SYN (en este caso, el cliente) efecta una apertura activa (active open), mientras que quien recibe el primer segmento SYN y enva el prximo segmento SYN (en este caso, el servidor) lleva a cabo una apertura pasiva (passive open). Puede darse el caso de que ambos extremos efecten una apertura activa en el mismo momento. Esta situacin se denomina apertura simultnea (simultaneous open). Ahora ya se ha establecido la conexin entre el cliente y el servidor.
Monitorizacin del establecimiento de una conexin utilizando el programa tcpdump Utilizaremos el programa tcpdump para ver cmo funciona el protocolo de establecimiento de una conexin. Asumimos que nos hemos conectado a una mquina llamada argos y hacemos un rlogin a la mquina helios. argos % rlogin helios Las primeras lneas que obtenemos con el tcpdump son las siguientes: 15:56:54.796091 argos.1023 > helios.login: S 3541904332: 3541904332 (0) win 31744 <mss 1460> 15:56:54.796091 helios.login > argos.1023: S 548133143: 548133143 (0) ack 33541904333 win 8760 <mss 1460> 15:56:54.796091 argos.1023 > helios.login: . ack 548133144 win 31744
En el anexo 1 de este mdulo didctico podis encontrar una descripcin del programa tcpdump.
FUOC P07/89013/00291
20
La interpretacin de las lneas es la siguiente: 1) argos, desde el puerto 1.023, enva a helios una peticin de conexin por medio de un segmento SYN. El nmero de secuencia inicial (ISN) elegido por argos es el 3.541.904.332, y argos anuncia que puede recibir 31.744 bytes sin reconocerlos y que espera recibir segmentos con un tamao mximo de 1.460 bytes. 2) helios responde con un segmento SYN eligiendo como ISN el nmero 548.133.143 y responde con un ACK con el byte siguiente que espera recibir de argos, el 3.541.904.333 (3.541.904.332 + 1). Anuncia que puede recibir 8.760 bytes y que espera recibir segmentos con un tamao mximo de 1.460 bytes. 3) argos reconoce el segmento SYN con un segmento en el que espera recibir el byte 548.133.144 (548.133.143 + 1). argos vuelve a advertir que est dispuesto a recibir hasta 31.744 bytes. A continuacin, empezara el intercambio de informacin entre el cliente y el servidor (por ejempo peticiones de login, contrasea, prompt de la mquina, etc.).
Actividad
Utilizad el programa tcpdump para ver el establecimiento de una conexin. Con esta finalidad, estableced una conexin con aplicaciones diferentes (telnet, ftp, rlogin, etc.) y monitorizad la conexin. Observad los segmentos de inicio de la conexin, el valor del nmero de secuencia inicial, el del nmero ACK inicial y el tamao de la ventana.
3.5. Terminacin de la conexin Cuando la transferencia de la informacin ha finalizado, el TCP dispone de un protocolo de terminacin de la conexin para cerrarla. En una conexin TCP full duplex, en la que los datos fluyen en ambos sentidos, independientes el uno del otro, cualquier conexin debe cerrarse independientemente. Es preciso tener en cuenta que tanto el cliente como el servidor pueden cerrar la conexin. Sin embargo, la situacin normal es que la aplicacin cliente inicie la peticin de conexin y tenga, posiblemente, un usuario interactivo que le pida su cierre por medio, por ejemplo, de una instruccin*. Por tanto, supongamos que es el cliente quien pide cerrar la conexin (si fuera el servidor, sera similar). Los pasos que se siguen son los siguientes: 1) El cliente enva un segmento TCP del tipo FIN con el nmero de secuencia correspondiente (J). Ello significa que a partir de este momento no habr ms datos que fluyan en este sentido (cliente servidor). 2) El servidor enva una confirmacin del cierre por medio de un ACK con el nmero de secuencia recibido ms 1 (J + 1). El TCP servidor indica a su aplicacin que el cliente cierra la conexin. La aplicacin servidor indica a su TCP que la cierre a continuacin. 3) El servidor enva un segmento TCP del tipo FIN al cliente con el nmero de secuencia correspondiente (K). 4) El TCP cliente responde automticamente con un ACK (K + 1).
Un segmento FIN... ... se llama de este modo porque tiene activado el bit FIN en el campo Control de la cabecera del segmento TCP.
* En un telnet esta instruccin sera un logout, en un ftp sera haciendo un bye, etc.
Recordad Un sistema orientado a la conexin efecta una fase de establecimiento de la conexin, una fase de transferencia de la informacin y una fase de cierre de la conexin.
FUOC P07/89013/00291
21
Se dice que quien enva el primer segmento FIN (en este caso el cliente) lleva a cabo un cierre activo (active close), mientras que quien lo recibe (en este caso el servidor) realiza un cierre pasivo (passive close).
Cabe destacar que la conexin que efecta el cierre activo entra en un estado denominado TIME_WAIT, de manera que deber esperar un tiempo (por norma general, una o dos veces el MSL) antes de utilizar de nuevo el mismo puerto. Lo ms habitual es que sea el cliente quien efecte el cierre activo. Como los clientes suelen utilizar puertos locales efmeros, este tiempo de espera no les afecta. En cambio, si es el servidor quien efecta el cierre activo, podemos encontrarnos con que no se pueda reinicializar durante 1 2 minutos. Ello sucede porque el servidor utiliza puertos conocidos que no se pueden volver a reasignar hasta que no acabe el procedimiento quiet time y se salga del estado TIME_WAIT.
Es posible que slo cierre la conexin (salida de datos) uno de los extremos, mientras que el otro (recepcin) se mantiene abierto. Esta situacin se denomina half-close, pero hay pocas aplicaciones que se aprovechen de ella. Lo ms normal es que ambas aplicaciones cierren sus canales de comunicaciones. Asimismo, puede darse el caso de que dos extremos efecten un cierre activo. Esta situacin se denomina cierre simultneo (simultaneous close).
Lectura complementaria Podis encontrar una seccin dedicada a este tema en el libro: W.R. Stevens (1998). TCP/IP Illustrated (vol. 1: The Protocols, cap. 19, pg. 252). Wilmington: AddisonWesley, 1994.
Monitorizacin de la terminacin de una conexin utilizando el programa tcpdump Utilizaremos el programa tcpdump para ver cmo funciona el protocolo de terminacin de la conexin. Asumimos que en el rlogin del ejemplo de establecimiento de la conexin helios hace un logout (pide el cierre de la conexin). helios % logout
FUOC P07/89013/00291
22
Las lneas que obtenemos con el tcpdump son las siguientes: 15:57:01.616091 helios.login > argos.1023: F 1417: 1417 (0) ack 41 win 8760 15:57:01.616091 argos.1023 > helios.login: .ack 1418 win 31744 15:57:01.616091 argos.1023 > helis.login: F 41:41 (0) ack 580 31744 15:57:01.616091 helios.login > argos.1023: .ack 42 win 8760
La interpretacin es la siguiente: Nota 1) helios enva un segmento con el indicador F (FIN). El nmero de secuencia es el 1.417 y enva 0 bytes de datos. Espera recibir el byte 41 de argos y advierte una ventana de 8.760 bytes. 2) argos enva un reconocimiento por medio de un segmento con ACK 1.418 (1.417 + 1) y advierte una ventana de 31.744 bytes. 3) Ahora le toca a argos cerrar su conexin TCP. Con esta finalidad, enva un segmento con el indicador F (FIN) a helios. El nmero de secuencia es el 41 (es el que esperar helios) y enva 0 bytes de datos. Advierte una ventana de 31.744 bytes. 4) helios recibe el segmento, lo reconoce con el ACK numerado como 42 (41 + 1) y advierte una ventana de 8.760 bytes. helios ha efectuado un cierre activo, mientras que argos ha efectuado un cierre pasivo. La notacin de nmeros de secuencia y nmeros ACK se establece a partir del ISN; es decir, un nmero de secuencia 1.417 indica un nmero de secuencia ISN + 1.417.
Actividad
Utilizad el programa tcpdump para ver el cierre de una conexin. Con esta finalidad, estableced una conexin con diferentes aplicaciones (telnet, rlogin, etc.) y supervisadla.
3.6. Diagrama de estados del TCP
En el diagrama de estados del TCP se describen los diferentes estados por los que pasa una conexin desde su establecimiento hasta su terminacin, incluyendo la etapa de transferencia de la informacin. Los nombres de los estados TCP son los mismos que se pueden consultar con la llamada al sistema netstat.
Lectura complementaria W.R. Stevens (1998). The Protocols TCP/IP Illustrated (vol. 1). Wilmington: Addison-Wesley, 1994.
El estado ESTABLISHED se corresponde con la transferencia de la informacin. El resto de los estados se corresponden con el establecimiento y la terminacin de la conexin, teniendo en cuenta todas las maneras posibles de establecer y cerrar una conexin en el TCP. Los smbolos SYN, RST, FIN y ACK se corresponden con los bits de indicacin de la cabecera TCP.
Un ejemplo de cmo se interpreta este diagrama sera el protocolo de terminacin de una conexin, en que ya vimos que el extremo TCP que peda el cierre efectuaba un cierre activo. Ello significa que pasara del estado ESTABLISHED al estado FIN_WAIT_1 enviando un segmento FIN.
FUOC P07/89013/00291
23
Desde aqu puede pasar a uno de los tres estados que describen cmo se puede realizar un cierre activo dependiendo de cmo se cierre la conexin: Con un cierre simultneo (simultaneous close), pasa a CLOSING. Con la recepcin de un ACK, pasa a FIN_WAIT_2, donde espera recibir un FIN. Con la recepcin de un FIN y un ACK, pasa a TIME_WAIT, donde espera dos veces el MSL antes de liberar el puerto. Ya hemos visto que el extremo TCP que recibe un FIN lleva a cabo un cierre pasivo. Por tanto, pasa del estado ESTABLISHED al estado CLOSE_WAIT enviando los indicadores ACK y FIN correspondientes para acabar la conexin. La fase de establecimiento tambin se puede seguir con facilidad por medio del diagrama de estados, teniendo en cuenta qu extremo efecta el cierre activo y cul lleva a cabo el cierre pasivo.
Consultad el MSL en el subapartado 3.5 de este mdulo didctico.
FUOC P07/89013/00291
24
Actividad
Utilizad el programa netstat para ver el estado de las conexiones TCP que tengis en este momento. Si no tenis ninguna aplicacin en la red, conectaos a algn servidor con la web, haced un ftp o un telnet a alguna mquina.
3.7. Transferencia de la informacin Una vez establecida la conexin, el TCP puede empezar la transferencia de segmentos TCP en ambos sentidos. Para tansmitir informacin de manera fiable, el TCP implementa protocolos de control de errores y de flujo. Los pasos que sigue el TCP para transferir la informacin son los siguientes: 1) Cuando el TCP enva datos, mantiene un temporizador (timeout) hasta que recibe un reconocimiento (ACK) del receptor. Si el temporizador salta, el TCP retransmite los datos. 2) Cuando el TCP recibe un segmento de datos, enva un reconocimiento. Este ltimo se puede retornar retrasado (no de inmediato) si el TCP lo considera necesario. 3) Si un segmento recibido es incorrecto (el checksum lo indica), el TCP descarta el segmento y no debera enviar la informacin. De hecho, como el TCP utiliza la tcnica de piggybacking (aprovecha los segmentos de datos que viajan en sentido contrario), lo que hace es retornar un segmento con el mismo nmero de ACK que haba reconocido la ltima vez. El transmisor ver un ACK con un nmero repetido e interpretar que no le reconocen la informacin*. En caso de que no tuviera datos para enviar en sentido contrario, el TCP puede enviar un segmento que no contenga informacin (con un campo de datos de cero bytes). Este segmento tendra el indicador ACK activado y reconocera los bytes pertinentes en el campo Nmero de ACK. El nmero de secuencia no se habra incrementado, puesto que no enva datos. 4) Si los segmentos llegan desordenados (por debajo hay el IP, que est no orientado a la conexin), el TCP reordena los segmentos y pasa los datos (bytes) correctamente ordenados a la aplicacin. Si recibe segmentos duplicados, el TCP descarta las copias. 5) Como el TCP posee una memoria limitada, es necesario que efecte un control de flujo. Con esta finalidad, cada extremo avisa de los datos que est dispuesto a recibir en cada momento utilizando el campo Ventana (se trata de un mecanismo de ventana deslizante basado en bytes que explicaremos ms adelante). El tipo de informacin que es preciso enviar puede dividirse en datos interactivos* y datos de gran volumen o bulk data**. La diferencia entre ellos radica en la cantidad de informacin que se transmite. Los datos interactivos transmiten pocos bytes de informacin (alrededor de 10), mientras que los datos de
* Por ejemplo, los que transmiten aplicaciones tales como telnet o rlogin. ** Por ejemplo, los que transmiten aplicaciones como correo electrnico o ftp. * Este nmero se denomina ACK duplicado.
FUOC P07/89013/00291
25
gran volumen transmiten gran cantidad de datos (ocupan la totalidad del tamao del segmento TCP). Conviene considerar que no es lo mismo cargar la red con paquetes pequeos de informacin que con paquetes grandes. El TCP puede aplicar en cada caso tcnicas diferentes de manera automtica, para aprovechar la red al mximo.
3.7.1. Transmisin de datos interactivos En este tipo de comunicacin, es normal enviar pocos datos. En una aplicacin del tipo Telnet, por ejemplo, un usuario cliente podra ejecutar el comando de UNIX ls y obtener un listado de un directorio por parte del servidor. En esta transferencia de informacin intervienen pocos bytes desde el origen (cliente) hasta el destino (servidor) y se utilizan conjuntamente dos tcnicas para obtener un mejor aprovechamiento de la red: Reconocimientos retrasados. Algoritmo de Nagle. Reconocimientos retrasados En este tipo de transferencia, es normal que el TCP no enve los reconocimientos ACK inmediatamente despus de recibir los datos, sino que est un tiempo esperando a que haya datos para enviar en sentido contrario. De este modo, puede utilizar la tcnica piggybacking y enviar el reconocimiento encapsulado en los datos que retornan al cliente. Es posible que el servidor se ahorre enviar un segmento que slo reconoce, pero que no contiene datos. Es tpico que el TCP espere (utiliza un temporizador) unos 200 ms por si hay datos para transmitir antes de enviar el ACK. Una vez ha transcurrido este tiempo, el TCP reconoce los datos recibidos hasta el momento con un segmento de datos, si dispone de datos para enviar en sentido contrario (piggybacking), o con un segmento sin datos (el nmero de secuencia no vara). En cualquiera de los dos casos, el indicador ACK estar activado y el nmero ACK reconocer los datos pertinentes. El TCP retrasa los ACK hasta 200 ms para aprovechar mejor la tcnica de piggybacking. Algoritmo de Nagle En numerosas ocasiones un cliente tiene muy pocos datos para enviar (por ejemplo, slo 1 byte). En este caso el TCP enviara un segmento slo con 1 byte de datos y con 20 bytes de cabecera TCP. El IP aadira 20 bytes ms de cabecera, lo que proporciona un total de 40 bytes de control y 1 de datos. Si se transmiten muchos segmentos de este tipo, la eficiencia es muy baja. Una solucin a esta baja eficiencia de transmisin es aplicar el algoritmo de Nagle.
FUOC P07/89013/00291
26
Utilizando el algoritmo de Nagle, una conexin TCP slo puede tener un segmento de tamao pequeo (pocos bytes) sin que se haya reconocido; es decir, slo puede haber un nico segmento de tamao pequeo viajando por la red (en vuelo). El resto de los segmentos de tamao pequeo no se pueden transmitir hasta que el ACK del segmento pequeo que est viajando por la red haya llegado. As, los segmentos que estn esperando para ser transmitidos se almacenan hasta que se recibe el ACK del segmento en vuelo. Cuando este ltimo llega, la conexin TCP puede enviar un segmento que contenga todos los datos almacenados hasta este momento, formando un segmento mayor. El algoritmo de Nagle funciona cuando los retrasos en la red son grandes; es decir, si la conexin cruza una WAN. En caso de que la conexin sea local, en una LAN, es difcil que se aplique este algoritmo a causa de la alta velocidad de la red. En ocasiones, es interesante desinhibir el algoritmo de Nagle, puesto que la aplicacin no puede esperar. El movimiento del ratn en X Windows System provoca segmentos pequeos. Estos movimientos del ratn deben entregarse sin retrasos para que el usuario interactivo no lo note. Las libreras de sockets deben permitir, activando indicadores , desinhibir el algoritmo de Nagle*.
* En la librera de sockets API, el indicador que desinhibe el algoritmo de Nagle es el TCP_NODELAY.
3.7.2. Transmisin de datos de gran volumen. Control de flujo por ventana deslizante En las comunicaciones en que se enva una ingente cantidad de datos de gran volumen (correo electrnico, transferencias FTP, etc.), como las memorias intermedias de recepcin se pueden llenar, es necesario un protocolo de ventana deslizante (sliding window) para controlar el flujo de datos. El TCP efecta un control de flujo por ventana deslizante, con la diferencia, respecto a los protocolos del nivel de enlace, de que en el TCP la ventana de transmisin es variable. La idea es que cada extremo TCP regula la cantidad de datos que el otro extremo puede transmitir. Con esta finalidad, cada extremo TCP notifica al extremo opuento, cada vez que enva un segmento, la ventana que puede aceptar en este momento. El TCP par actualiza su ventana de transmisin de acuerdo con este valor. Mientras que el TCP transmisor marca los bytes que ha transmitido con un nmero de secuencia, el TCP receptor retoma los bytes que recibe y los reconoce (por norma general, por medio de la tcnica de piggybacking) con un ACK. Los reconocimientos ACK especifican siempre el nmero de secuencia del prximo octeto que el receptor espera recibir.
FUOC P07/89013/00291
27
Un reconocimiento reconoce posiciones de bytes en el flujo de datos hasta la ltima posicin que ha recibido correctamente, sin tener en cuenta el segmento al que pertenecen.
El TCP slo activa un temporizador de retransmisiones que reprograma cuando recibe un reconocimiento o cuando salta el temporizador. Ms adelante veremos cmo el TCP programa el temporizador de retransmisiones. La cabecera del segmento TCP especifica tres parmetros esenciales en el funcionamiento del protocolo de ventana deslizante:
El nmero de secuencia, que indica a su conexin opuesta el primer byte de datos que contiene el segmento transmitido.
El nmero de reconocimiento (nmero ACK), que indica a su conexin opuesta el prximo byte que espera recibir y, por tanto, el ltimo byte recibido correctamente. Conviene recordar que el TCP es bidireccional y que un segmento TCP reconoce, por medio de piggybacking, los datos que recibe con un ACK que debe estar numerado.
La ventana, que indica a su conexin opuesta el tamao de la memoria intermedia de recepcin y, por tanto, el tamao de la ventana que el transmisor debe utilizar.
Actividad
Asumimos que un extremo cliente TCP ha elegido el 28.325 como nmero de secuencia inicial (ISN), mientras que el extremo servidor TCP ha elegido como ISN el 12.555. Qu indica un segmento cliente TCP con nmero de secuencia 29.201, nmero ACK 12.655 y ventana 1.024? Solucin El nmero de secuencia indica que el cliente ya ha transmitido desde el byte 28.325 hasta el byte 29.200 (875 bytes en total) y que en este segmento transmitir a partir del byte 29.201. El nmero ACK indicar al servidor que el cliente ha recibido correctamente hasta el byte 12.654 y que espera recibir a partir del 12.655. La ventana indica al servidor que el cliente slo puede aceptar 1.024 bytes antes de confirmarlos. Por consiguiente, el servidor TCP actualizar su ventana de transmisin a 1.024.
Con el objetivo de estudiar el mecanismo de ventana deslizante, analizaremos un caso sencillo. Asumiremos que ya se ha establecido la conexin y se han asignado los ISN para ambos extremos.
En la figura siguiente, podemos ver cmo funcionara el protocolo de ventana deslizante para el TCP transmisor. El TCP receptor le ha indicado que est dispuesto a recibir 7 bytes. Por tanto, la ventana de transmisin del TCP transmisor es de 7 bytes.
FUOC P07/89013/00291
28
Podemos interpretar la ventana deslizante de la manera siguiente: 1) El TCP ya ha enviado bytes hasta el nmero de secuencia 1.003. De estos bytes, el TCP receptor le ha reconocido hasta el 999; faltan por reconocerle los bytes 1.000 a 1.003. 2) Como la ventana de transmisin es de 7 bytes y ya ha transmitido 4, el TCP todava puede transmitir 3 bytes antes de agotarla (bytes 1.004 a 1.006). 3) El TCP slo podr transmitir del byte 1.007 en adelante en los casos siguientes: Si el TCP receptor le reconoce los bytes a partir del 1.000, de manera que el lmite izquierdo de la ventana se mover hacia la derecha. Si el TCP receptor le advierte de una ventana superior a 7, de manera que el lmite derecho de la ventana se mover hacia la derecha. Una combinacin de las dos soluciones anteriores. Como podis observar, el TCP receptor puede advertir una nueva ventana de transmisin. Cada vez que reconozca datos, avisar de la nueva ventana que est dispuesta a recibir. El TCP transmisor actualizar esta ltima.
La ventana puede experimentar tres tipos de movimiento: 1) La ventana se cierra al moverse el lmite izquierdo hacia la derecha cuando los datos enviados son reconocidos. 2) La ventana se abre al moverse el lmite derecho hacia la derecha y permite que el TCP enve ms datos. Esta apertura tiene lugar cuando el receptor libera espacio de su memoria y puede advertir una nueva ventana. 3) La ventana se comprime cuando el lmite derecho se mueve hacia la izquierda.
FUOC P07/89013/00291
29
Algunos puntos que podemos resumir de la figura de la ventana deslizante son los siguientes: Si el lmite izquierdo alcanza el lmite derecho, se dice que la ventana vale cero (zero window). Ello hace que el transmisor detenga el envo de datos. Se recomienda que el TCP transmisor no comprima la ventana de transmisin. Es preciso que distingamos el hecho de que la ventana se comprima (el lmite derecho se mueve hacia la izquierda) del hecho de que la ventana disminuya de tamao (se advierte una ventana ms pequea, pero el lmite derecho no se mueve hacia la izquierda).
Diferencia entre compresin y disminucin de tamao de la ventana Supongamos una ventana de 7 bytes como en la figura de la ventana deslizante. El receptor reconoce los bytes 1.000 a 1.003 y advierte una ventana de 5 bytes. Como podis deducir, el lmite izquierdo vale ahora 1.004; el lmite derecho, 1.008 (se ha movido hacia la derecha), y la nueva ventana, 5. En este caso, la ventana de recepcin debe reducirse, pero no se ha comprimido. En cambio, si el receptor slo reconoce 1 byte (el byte 1.000) y advierte una ventana de 1 byte, el transmisor se encontrar con un problema. Una ventana de 1 byte significa que slo poda haber transmitido 1 (el 1.001), pero ya haba transmitido 3, incluyendo el reconocido (del 1.000 al 1.003). Por tanto, el receptor debe asegurarse de advertir al menos tantos bytes como el transmisor le puede haber enviado con la ventana anterior. Si slo reconoce 1 byte, la ventana advertida debe ser de 6 bytes; si reconoce los 4 bytes, esta ltima debe ser, al menos, de 3 bytes, puesto que el transmisor ya los podra haber transmitido. Ejemplo de funcionamiento del protocolo de ventana deslizante Utilizaremos el programa tcpdump para observar cmo funciona el protocolo de ventana deslizante. Asumimos que hemos efectuado un rlogin de argos a helios (argos % rlogin helios) y ya estamos conectados a helios. Una vez nos encontramos en helios, ejecutamos el comando ls. Este ltimo retorna por salida estndar el listado de directorios del directorio del usuario (home directory) en helios que ocupan 811 caracteres (representa el envo de 811 bytes). helios % ls Las lneas que obtenemos con el programa tcpdump (numeradas del 1 al 13) son las siguientes: 1) 2) 3) 4) 5) 6) 7) 8) 9) 15:56:59.506091 argos.1023 > helios.login: P 37:38 (1)ack 596 win 31744 15:56:59.516091 helios.login > argos.1023: P 596:597 (1) ack 38 win 8760 15:56:.59.526091 argos.1023 > helios.login: .ack 597 win 31744 15:56:59.846091 argos.1023 > helios.login: P 38:39 (1)ack 597 win 31744 15:56:59.856091 helios.login > argos.1023: : P 597:600 (3) ack 39 win 8760 15:56:59.866091 argos.1023 > helios.login: .ack 600 win 31744 15:57:00.116091 argos.1023 > helios.login: P 39:40 (1)ack 600 win 31744 15:57:00.126091 helios.login > argos.1023: P 600:603 (3) ack 40 win 8760 15:57:00.136091 argos.1023 > helios.login: .ack 603 win 31744 Notacin Cuando el tcpdump dice 597:600 quiere decir que este segmento incluye 3 bytes: 597, 598 y 599. El nmero detrs de los dos puntos (:) indica el primero que espera, no el ltimo que ha recibido.
FUOC P07/89013/00291
30
10) 15:57:00.146091 helios.login > argos.1023: P 603:658 (55) ack 40 win 8760 12) 15:57:00.166091 helios.login > argos.1023: P 658:1414 (756) ack 40 win 8760 13) 15:57:00.176091 argos.1023 > helios.login: .ack 1414 win 31744 La interpretacin de estas lneas es la siguiente: argos ya ha enviado 36 bytes, mientras que helios ya ha enviado 595 (informacin que ambos han intercambiado desde el principio de la conexin, como pueden ser logins, usernames, etc.). Deducimos esta informacin de la primera lnea del ejemplo. 1) argos enva el carcter l. El indicador P seala PUSH. El nmero de secuencia avanza de 37 a 38. 2) helios retorna un eco del carcter l. Su nmero de secuencia avanza de 596 a 597 y reconoce el byte recibido (ACK = 37 + 1 = 38). 3) argos reconoce el eco: ACK = 597 + 1 = 598. 4) argos enva el carcter s. El nmero de secuencia avanza de 38 a 39. El ACK no reconoce nada porque vale igual que antes: ACK = 597. 5) helios hace un eco que ocupa 3 bytes (BS* + l + s). El nmero de secuencia avanza tres posiciones (de 597 a 600) y reconoce el carcter s , puesto que ACK = 38 + 1 = 39. 6) argos reconoce el eco con un ACK = 600. 7) argos enva el retorno de carro (CR). El nmero de secuencia avanza una posicin. 8) helios hace un eco del CR y, asimismo, retorna otro CR seguido de un LF*. Ello significa el envo de 3 bytes. Reconoce el CR, puesto que ACK = 40. 9) argos reconoce estos tres caracteres. 10) helios responde a ls enviando 55 de los 811 bytes que debe enviar. El nmero de secuencia avanza de 603 a 658. El ACK se mentiene a 40. 11) argos reconoce estos 55 bytes enviando un ACK de 659. 12) helios transmite el resto de los 811 bytes, es decir, 756 bytes. 13) argos reconoce estos bytes avanzando el ACK a 1.414. Como podemos observar en este ejemplo, el TCP divide la informacin que hay que enviar en dos segmentos: un segmento de 55 bytes y otro de 756 bytes. Conviene remarcar que rlogin enva los comandos carcter a carcter y que, adems, la aplicacin remota hace un eco de estos caracteres. Por ello, en las primeras lneas se enva primero la l, despus la s, a continuacin el retorno de carro, etc. Lo que nos interesa de este ejemplo es ver cmo avanzan las ventanas al emitir y al reconocer bytes. Por tanto, no justificaremos por qu rlogin retorna ecos, ni por qu aade un carcter LF al retorno de carro.
* LF es la sigla de line feed. * BS es la sigla de back space.
Recordad PUSH indica al receptor que pase los datos inmediatamente a la aplicacin; es decir, que no los deje durante un tiempo en la memoria intermedia de recepcin.
3.7.3. Temporizadores y retransmisiones El TCP activa hasta cuatro temporizadores de diferente tipo para conseguir una entrega fiable de la informacin. En este subapartado nos centraremos nicamente en el temporizador de retransmisiones o RTO*. Conviene recordar que tanto los segmentos como los reconocimientos se pueden perder durante la transmisin, de manera que es preciso utilizar un temporizador de retransmisiones.
* RTO es la sigla de retransmission time out.
FUOC P07/89013/00291
31
Como ya hemos mencionado, el temporizador se programa cada vez que se recibe un reconocimiento, o bien cuando salta porque el reconocimiento no ha llegado a tiempo (o, simplemente, no ha llegado).
Definimos el tiempo de ida y vuelta o RTT* como el tiempo que transcurre desde que se transmite un segmento, hasta que es reconocido (el ACK vuelve al transmisor). El RTT se puede medir restando el instante en que el TCP transmisor emite el segmento y el instante en que recibe el ACK.
* RTT es la sigla de round trip time.
Lo ms lgico sera activar el temporizador de retransmisin en el tiempo de ida y vuelta (RTO = RTT). Sin embargo, es evidente que los retrasos que experimentan los segmentos son variables: si se activa el RTO en el RTT que ha experimentado el segmento anterior, no se puede asegurar que este segmento no tenga un retraso superior y que el temporizador no salte antes de tiempo. Existen diferentes alternativas para programar el temporizador que explicaremos a continuacin: Algoritmo de retransmisin adaptativo. Algoritmo de Jacobson para calcular el RTO. Algoritmo de Karn. Algoritmo slow start. Algoritmo congestion avoidance. Temporizador keepalive. Algoritmo de retransmisin adaptativo Se utiliza una estimacin del RTT que considere el RTT medido y su ltimo valor estimado del RTT. El nuevo RTT estimado (Est_RTT) se calcula de la manera siguiente: Est_RTT = Est_RTT + (1 ) M_RTT. Se recomienda que el temporizador valga: RTO = Est_RTT, El problema de esta aproximacin es que no considera las fluctuaciones del RTT, lo que provoca ms retransmisiones de las necesarias. Para solucionar este problema, se propuso un estimador del RTT que tuviera en cuenta la varianza del RTT. Algoritmo de Jacobson para calcular el RTO Este algoritmo mejora el clculo del temporizador del algoritmo de retransmisin adaptativo. Jacobson propuso calcular el temporizador de retransmisiones RTO utilizando la media y la varianza del RTT.
es el factor de variacin del retraso y se recomienda que valga 2. M_RTT es el ltimo RTT medido (M_RTT o Measured RTT) y es un factor cuyo valor se recomienda que sea 0,9 (el 90% del valor de la nueva estimacin proviene de la ltima estimacin del RTT y el 10% restante, de la ltima medida del RTT).
FUOC P07/89013/00291
32
Tenemos que MRTT es la media estimada del RTT y que SRTT es la desviacin estndar estimada. De este modo, el temporizador tendr en cuenta las fluctuaciones en el retraso que puede experimentar un segmento al cruzar equipos intermedios en una red. El algoritmo consiste en los pasos siguientes:
Las variables MRTT y SRTT se inicializan a 0 y 3 segundos respectivamente, y el valor de g es 1/8 y el de h es 1/4.
Podemos notar que el clculo de la media MRTT es equivalente al estimador adaptativo, con la diferencia de que g = (1 ) y adopta un valor diferente. Por ltimo, el temporizador se actualiza como una funcin de la medida y de la desviacin estndar (o varianza, puesto que estn relacionadas) del RTT: RTO = MRTT + 2 SRTT para el primer temporizador. RTO = MRTT + 4 SRTT a partir del primer temporizador. Algoritmo de Karn Cuando el temporizador salta, el segmento se retransmite y el TCP reprograma el temporizador. Supongamos que a continuacin se recibe un ACK. El TCP no tiene manera de saber a quin pertenece (al primer segmento o a su retransmisin), puesto que el ACK slo indica el prximo byte que espera recibir. Esta situacin se denomina problema de ambigedad en las retransmisiones y afecta a la manera de recalcular el RTO, puesto que este ltimo depende de las medidas del RTT que llevamos a cabo. Es decir, debemos pensar que uno de los parmetros que se utiliza para calcular el valor del temporizador es la medida del tiempo de ida y vuelta (M_RTT). Si para medir el RTT, el TCP utiliza el ACK que llega despus de haber retransmitido uno o diferentes segmentos y se produce un problema de ambigedad en las retransmisiones, el TCP puede computar valores que no son reales con la situacin actual de la red. Para evitarlo, se utiliza el algoritmo de Karn. El algoritmo de Karn considera que el RTO slo se recalcular por medio de una estimacin del RTT (es decir, utilizando un algoritmo como el de Jacobson) si el reconocimiento pertenece a un segmento no retransmitido. Cuando se produce una retransmisin, se utiliza un algoritmo de back-off exponencial para doblar el valor del temporizador. El algoritmo de back-off dobla el valor del ltimo RTO hasta un lmite de 64 segundos. Cuando se reciba un ACK de un segmento que no se ha retransmitido, se vuelve a tomar una medida del RTT y se aplica de nuevo el algoritmo de Jacobson. Desde un punto de vista experimental, se ha comprobado que este algoritmo funciona muy bien incluso cuando la red experimenta muchas prdidas de datos.
FUOC P07/89013/00291
33
Algoritmo slow start En numerosas ocasiones el transmisor empieza emitiendo el mayor nmero de segmentos posible (tantos como le permite su ventana). Una vez ha agotado la ventana, el transmisor espera que el receptor le reconozca los datos y le advierte de nuevas ventanas para continuar funcionando y emitir ms datos. Sin embargo, en una red hay equipos intermedios (direccionadores, conmutadores, etc.) que pueden congestionarse. Por tanto, no podrn almacenar tanta informacin como el transmisor est emitiendo.
Los equipos intermedios se pueden congestionar por muchas razones: por ejemplo, a causa de un direccionador con enlaces de entrada a alta velocidad y enlaces de salida a baja velocidad, o con una CPU lenta o con memoria intermedia pequea. Asimismo, conviene considerar que el direccionador, adems de retransmitir la informacin, debe direccionarla. Por tanto, no slo debe procesar los datagramas IP que recibe, sino que en ocasiones debe computar algoritmos de direccionamiento.
Es muy posible que estos equipos, para descongestionarse (tienen las memorias intermedias completas), descarten datagramas IP. Al fin y al cabo, por encima del IP hay un protocolo de retransmisiones (TCP) que retransmitir toda la informacin que no haya llegado a su destino. El problema surge cuando el TCP se percata de que la informacin no ha llegado a su destino (los datagramas IP con esta informacin han sido descartados por el direccionador) y vuelve a retransmitir la ventana. El direccionador se encuentra de nuevo con la misma situacin, o incluso peor*, y vuelve a descartar datagramas IP de esta conexin. El direccionador necesita aliviar la congestin; es decir, que las conexiones no le enven demasiados datagramas IP y as tenga tiempo de recuperarse. Un algoritmo que el TCP puede implementar para evitar la congestin de los equipos intermedios de la red es el slow start. El algoritmo slow start permite que el transmisor incremente el nmero de segmentos que es preciso transmitir exponencialmente cada vez que reciba un reconocimiento. El transmisor empieza transmitiendo un solo segmento. El slow start define una segunda ventana a la que llama ventana de congestin. El algoritmo funciona de la manera siguiente: 1) La ventana de congestin se inicializa en el valor de un segmento de tamao mximo (MSS bytes). 2) Cada vez que se recibe un ACK, la ventana de congestin se incrementa en un segmento (en MSS bytes). 3) El transmisor puede emitir lo mnimo entre la ventana de transmisin y la ventana de congestin.
Cuando el algoritmo slow start... ... incrementa la ventana de congestin en un segmento, lo que hace es considerar un segmento como el nmero de bytes que ocupa un segmento de tamao mximo.
*La razn de este empeoramiento es que el direccionador recibe de nuevo los datagramas de las conexiones que haba rechazado y todos al mismo tiempo, lo que no le ayuda a eliminar la congestin.
FUOC P07/89013/00291
34
De esta manera, el transmisor no enviar en un inicio toda su ventana de transmisin. A medida que recibe el ACK, asume que no hay congestin e incrementa lentamente la cantidad de datos a transmitir.
La ventana de transmisin es un control de flujo impuesto por el receptor, mientras que la ventana de congestin consiste en un control de flujo impuesto por el transmisor. Es conveniente considerar que el incremento de la ventana de congestin es exponencial. En un inicio, vale un segmento. Cuando el transmisor recibe un ACK, incrementa la ventana de congestin a dos segmentos. Ahora recibir 2 ACK, de manera que podr incrementarla a cuatro segmentos. Y as continuamente.
Algoritmo congestion avoidance
El algoritmo slow start evita que se congestione un equipo intermedio que no est congestionado en un inicio. Sin embargo, ello no es suficiente para evitar la congestin: en algn momento la ventana de congestin ser mayor que la de transmisin, de manera que el TCP siempre transmitir toda su ventana. Si el equipo intermedio se congestiona, debe disminuirse el nmero de segmentos a transmitir y volver a aplicar un algoritmo como el slow start.
Sabremos que hay congestin cuando el receptor no reconozca los datos. Ello significa que el temporizador de retransmisin saltar porque no ha llegado un ACK o porque ha llegado un ACK con el mismo nmero que el anterior (se llama ACK duplicado).
Recordad... ... que un ACK duplicado es un segmento con el mismo nmero ACK que el segmento anterior.
El algoritmo de congestion avoidance reduce la ventana de congestin a la mitad cada vez que se pierde un segmento, y reduce la congestin en la red. Para ello, define un umbral (threshold) y trabaja junto con el slow start de la manera siguiente:
El TCP inicializa el umbral (threshold) a 65.535 bytes y la ventana de congestin a un segmento (MSS bytes). En un inicio, el transmisor est en estado slow start.
El transmisor enva datos de acuerdo con el algoritmo slow start.
Si el transmisor detecta congestin (el temporizador salta o recibe un ACK duplicado), actualiza el valor del umbral a la mitad del valor de la ventana de congestin que hay en este momento; pero nunca por debajo de dos segmentos, y reinicializa la ventana de congestin a un segmento volviendo al estado slow start:
threshold = mx(2 MSS, (ventana de congestin) / 2)
FUOC P07/89013/00291
35
Cuando recibe un ACK, debe incrementar el valor de la ventana de congestin teniendo en cuenta las situaciones siguientes: Si la ventana de congestin es inferior o igual que el umbral, el transmisor est en un estado de no congestion avoidance y la ventana de congestin se incrementa en un segmento cada vez que se recibe un ACK. El incremento es exponencial, puesto que se corresponde con el algoritmo slow start. Si la ventana de congestin es mayor o igual que el umbral, el transmisor se encuentra en un estado de congestion avoidance y la ventana de congestin se incrementa en 1/(ventana de congestin) cada vez que se recibe un ACK, de manera que el incremento es lineal. Temporizador keepalive Cuando una conexin TCP no dispone de datos para emitir, no se enva ningn tipo de informacin (por ejemplo, de control) entre el cliente y el servidor. Ello significa que la conexin puede estar horas o das abierta si la aplicacin no la cierra. Puede darse el caso de que la mquina haya cado, o haya rebotado, en uno de los extremos y que la otra no se haya dado cuenta puesto que no ha habido ningn tipo de intercambio de informacin entre los extremos. El temporizador keepalive no forma parte de la especificacin TCP, aunque es interesante saber qu hace, puesto que existen algunas versiones TCP que lo implementan. Se recomienda que sea la aplicacin la que active este temporizador si le interesa. Si no hay actividad durante dos horas (valor del temporizador keepalive), el servidor enva un segmento de prueba al cliente. Se pueden dar cuatro situaciones: Si el cliente todava corre, responde, y el servidor reinicializa el temporizador keepalive dos horas despus. Si durante estas ltimas hay intercambio de datos, el temporizador se reinicializa dos horas despus del mismo. Si el TCP cliente ha cado y no ha rebotado, el servidor enva hasta diez segmentos de pruebas cada 75 segundos. Si no recibe respuesta, el servidor cierra la conexin. Si la mquina cliente ha cado y ha rebotado, el servidor recibir una respuesta para que cierre la conexin. El cliente est corriendo, pero no es asequible (por ejemplo, ha cado algn direccionador y no hay manera de llegar a l). Esta situacin es equivalente a la segunda, puesto que el servidor no tiene manera de saber si el cliente no es asequible a causa de un error de la red o de una cada de la mquina. Si la mquina cliente simplemente ha rebotado, el proceso aplicacin cliente habr cerrado la conexin TCP enviando un segmento FIN al servidor.
Keepalive El valor por defecto del temporizador es de dos horas, aunque puede activarse con otro valor.
FUOC P07/89013/00291
36
Resumen
El objetivo principal de este mdulo didctico ha sido introducir los protocolos del nivel de transporte que se utilizan en la red Internet. El objetivo principal del nivel de transporte es entregar la informacin a los niveles orientados a la aplicacin en los extremos de la red. En la jerarqua de protocolos TCP/IP se definen dos protocolos de transporte: 1) El UDP, que es un protocolo no orientado a la conexin. Por lo tanto, no efecta ningn control de errores ni de flujo. Si un datagrama UDP llega equivocado (el UDP utiliza un cdigo detector de errores), el UDP lo descarta y no lo entrega a la aplicacin. sta tendr que ser capaz de responder a este tipo de servicio o tendr que asumir la prdida de la informacin. Este tipo de servicio puede ser til en aplicaciones en tiempo real, en las que es ms importante que la informacin llegue cuando le corresponde es decir, con un retraso delimitado, que no que se pierda una parte. 2) El TCP, que es un protocolo orientado a la conexin. Habr una fase de establecimiento de la conexin (el llamado procedimiento three-way handshake), una fase de transmisin de la informacin y una fase de terminacin de la conexin. El TCP entregar la informacin a la aplicacin totalmente libre de errores. Para conseguirlo, necesita efectuar un control de errores y de flujo. El TCP utiliza un cdigo detector de errores conjuntamente con un protocolo de retransmisiones para recuperar la informacin errnea. Como las memorias intermedias de recepcin se pueden desbordar, el TCP utiliza un control de flujo por ventana deslizante. El TCP tiene que dimensionar correctamente los temporizadores de retransmisin. Hay diferentes algoritmos, entre los cuales destaca el de Jacobson, basado en una estimacin del RTT (tiempo de ida y vuelta de la informacin entre los extremos TCP), y el clculo de la medida y la varianza del RTT. Tambin hemos estudiado los algoritmos que el TCP utiliza para aliviar la congestin en la red: slow start y congestion avoidance.
FUOC P07/89013/00291
37
Ejercicios de autoevaluacin
1. Cuando se establece una conexin entre las estaciones argos y helios, tiene lugar el proceso siguiente: 15:56:54.796091 argos.1023 > helios.login S 3541904332: 3641904331 (0) win 31744 <mss 1460> 15:57:00.796591 argos.1023 > helios.login S 3541904332: 3641904331 (0) win 31744 <mss 1460> 15:57:13.797035 argos.1023 > helios.login S 3541904332: 3641904331 (0) win 31744 <mss 1460> 15:57:13.797035 helios.login > argos.1023 S 548133143: 548133143 (0) ack 34519043333 win 8760 <mss 1460> 15:56:54.797035 argos.1023 > helios.login .ack 548133144 win 31744 El primer temporizador de argos se inicializa a 6 segundos. Determinad cunto valen el segundo y el tercer temporizador de argos. 2. Un TCP transmisor ha advertido, durante el establecimiento de una conexin, un MSS de 512 bytes y durante la transferencia de la informacin advierte una ventana de 512 bytes. Un TCP receptor advierte ventanas de 2.048 bytes. Dibujad un diagrama de tiempo en el que se perciba el algoritmo slow start.
FUOC P07/89013/00291
38
Solucionario
Ejercicios de autoevaluacin
1. El primer Tout est inicializado a 6 segundos. De las trazas del tcpdump podemos deducir que el servidor en helios no responde y que el temporizador ha saltado. argos ha retrasnmitido una peticin de conexin y activa el temporizador por medio del algoritmo de Karn; es decir, mediane el algoritmo de back off para calcular el nuevo valor del T out: T out = 2 Tout = 12 s. helios no responde a la segunda peticin de argos. Por tanto, despus de 12 segundos, el temporizador salta y argos vuelve a retransmitir la peticin de conexin. Ahora vuelve a utilizar el algoritmo de back off para calcular el temporizador. Ello significa que Tout valdr lo siguiente: T out = 4 T out = 24 s. 2. El diagrama de tiempo en que se representa el algoritmo slow start por la transimisin indicada es el siguiente:
Como puede observarse, el slow start empieza enviando un segmento de tamao MSS. En un inicio, la ventana de congestin es igual a MSS (512 bytes) y la ventana de transmisin tiene una longitud de 2.048 bytes. La secuencia de acontecimientos es la siguiente: a) El TCP transmisor enva un segmento de tamao MSS = 512 bytes. El TCP receptor reconoce estos 512 bytes con un ACK. b) El slow start incrementa su ventana de congestin en dos segmentos: Ventana de congestin = 2 MSS = 1.024 bytes.
FUOC P07/89013/00291
39
Puede enviar el mnimo entre la ventana de congestin y la ventana de transmisin. Ello significa que puede enviar 1.024 bytes. Como el tamao mximo de los segmentos es de 512 bytes, entonces transmite dos segmentos. El TCP receptor reconoce estos 1.024 bytes con un ACK. c) El ACK reconoce dos segmentos; por tanto, el slow start puede incrementar la ventana de congestin en un segmento por cada uno de los ACK que recibe. Aunque fsicamente slo reciba un solo ACK, este ltimo vale por dos. Por tanto, la ventana de congestin aumenta de dos segmentos a cuatro: Ventana de congestin = 4 MSS = 2.048 bytes. Ahora puede transmitir lo mnimo entre la ventana de congestin y la de transmisin. Ello significa que puede transmitir 2.048 bytes divididos en cuatro segmentos de tamao mximo. El receptor reconoce estos cuatro segmentos con un ACK. d) El TCP transmisor recibe un ACK que vale por cuatro segmentos. Incrementa la ventana de congestin a 8 segmentos: Ventana de congestin = 8 MSS = 4.096 bytes. Sin embargo, la ventana de transmisin contina valiendo 2.048 bytes. Ello significa que no puede transmitir ms de 2.048 bytes, es decir, cuatro segmentos de tamao mximo.
Glosario
address resolution protocol m Vase ARP. checksum m Dgitos de control que se obtienen haciendo operaciones matemticas (bsicamente sumas) con los bits de datos. Ethernet m Estndar de facto parcialmente compatible con el IEEE802.3. Ambos utilizan el algoritmo CSMA/CD 1 persistente a 10 Mbps o 100 Mbps. Ethernet (red de ter) hace alusin tanto al hecho de que antiguamente se crea que el espacio que separaba a los astros estaba formado por un material (ter) capaz de transportar la luz, como al hecho de que la arquitectura de su red competidora, la Token Ring, necesitaba bastantes ms elementos, aparte del ter. ICMP m Protocolo de nivel de red utilizado slo para tareas de gestin del nivel de red. en Internet control message protocol IEEE m Asociacin de Estados Unidos dedicada, entre otras cosas, a tareas de estandarizacin. en Institute of Electric and Electronic Engineers initial sequence number m Vase ISN. Institute of Electric and Electronic Engineers m Vase IEEE. Internet control message protocol m Vase ICMP. Internet protocol m Vase IP. IP m Protocolo de nivel de red utilizado en Internet. en Internet protocol ISN m Nmero de secuencia inicial que es asignado al principio de la conexin. A partir de este momento, el TCP numera los bytes consecutivamente a partir de este nmero. en initial sequence number LAN f red de rea local. en local area network local area network f Vase LAN. MAC m Protocolo de control de acceso al medio utilizado por las estaciones de una misma red de rea local como, por ejemplo, Ethernet o IEEE802.5 (Token Ring). en medium access control maximum segment size f Vase MSS. medium access control m Vase MAC.
FUOC P07/89013/00291
40
MSS f Define la longitud mxima de datos que el TCP enviar. Se especifica durante el establecimiento de la conexin. en maximum segment size read only memory f Vase ROM. ROM f Memoria slo de lectura utilizada para almacenar datos y/o programas pequeos. en read only memory temporizador m Cdigo que al ejecutarse cuenta el paso del tiempo.
Bibliografa
Comer, D.E. (2006). Principles, Protocols and Architecture. Internetworking with TCP/IP (5a. ed., vol. 1). Hertfordshire: Prentice Hall. Este libro proporciona una visin muy prctica de la red Internet. Explica los principios de funcionamiento y da detalles de implementacin de la mayora de protocolos definidos. Con respecto a este mdulo, los captulos 11 y 12 son los ms interesantes porque es donde se presentan los protocolos del nivel de transporte. Stevens, W.R. (1998). The Protocols TCP/IP Illustrated (vol. I). Wilmington: AddisonWesley, 1994. Este libro es una completa y detallada gua de todos los protocolos presentes en Internet. Una de sus principales caractersticas es que no se cie en describir los protocolos, sino que ilustra su funcionamiento a travs de situaciones concretas. Para la parte de transporte, son tiles los captulos 11, 12 y del 17 al 24. Wright, G.R.; Stevens, W.R. (1995). The implementation. TCP/IP Illustrated (vol. II). Wilmington: Addison-Wesley. Este libro es un complemento del anterior. Si en el volumen I se describen los protocolos, en este volumen II se muestran posibles implementaciones de estos protocolos. Se trata, pues, de una visin orientada al ejemplo concreto, ms que de la pura descripcin. Es muy interesante, sobre todo para aquellos que se quieran dedicar a la programacin de protocolos. La parte de transporte est tratada en los captulos 24 al 30. Kurose, J.; Ross, K. (2006). Computer Networking: A Top-Down Approach Featuring the Internet (3. ed.). Boston: Addison-Wesley. Este libro proporciona una visin completa de los diferentes aspectos relacionados con las redes de ordenadores. El captulo 3 est dedicado a explicar la capa de transporte en general y los protocolos que se hacen servir en Internet a este nivel: UDP y TCP.
FUOC P07/89013/00291
41
Anexos
Anexo 1 Aplicaciones mencionadas en el texto
1) Aplicaciones estndar A continuacin, mostramos las aplicaciones estndar que se han explicado en este mdulo didctico e indicamos los sistemas en que se pueden encontrar y qu utilidades tienen: ping [UNIX, NT, MSWindows]: por medio de paquetes ICMP (del tipo peticin de eco y respuesta de eco) permite saber si una mquina est funcionando o no y tener una idea de cul es el retraso de ida y vuelta (round-trip). Asimismo, permite saber por qu mquinas pasa el paquete hasta que llega a destino. Para esta funcin, va mejor el programa traceroute, a causa de las limitaciones inherentes a los paquetes ICMP. traceroute [UNIX, NT: tracert, MSWindows: tracert]: permite averiguar la ruta que se sigue desde el equipo local hasta un destino cualquiera de Internet. Marca los retrasos existentes en cada uno de los nodos que es preciso cruzar. Se basa en el campo TTL del paquete IP y los mensajes ICMP-time-to-live-exceeded. Esta aplicacin no est disponible en algunas distribuciones de UNIX; s que se puede conseguir como programa de libre distribucin (freeware) en cdigo fuente (lenguaje C). arp [UNIX, NT, MSWindows]: permite consultar y modificar la tabla ARP (cach ARP) de una mquina. route [UNIX, NT, MSWindows]: sirve para consultar y modificar la tabla de direccionamiento IP de una mquina conectada a Internet. ifconfig [UNIX, NT: ipconfig, MSWindows: ipconfig]: permite consultar el estado de las tarjetas de red disponibles en el sistema local. netstat [UNIX, NT, MSWindows]: proporciona estadsticas de los protocolos TCP y UDP. Permite listar los puertos que se escuchan. Muestra el estado en que se encuentran los sockets TCP. Si queris un listado de todos los sockets activos y puertos abiertos, haced netstat -a, y, si os interesan otras variantes, consultad la ayuda (netstat -help en Windows, o man netstat en UNIX). telnet [UNIX, NT, MSWindows]: ofrece, aparte de la principal emulacin de terminal, conectar y experimentar los protocolos ASCII. 2) Aplicaciones no estndar netcat [UNIX, NT, MSWindows (freeware-lenguaje C)]: esta aplicacin nos permite utilizar conexiones TCP y UDP desde la lnea de comandos (por ejemplo, transmitir un fichero) o comprobar qu puertos tiene abiertos una determinada mquina, entre otros servicios. Su autor es Hobbit. tcpdump [UNIX (freeware-lenguaje C)]: permite analizar el trfico de la red por medio de conexin (LAN o punto a punto). Al contrario de lo que su nombre indica, es capaz de interpretar los paquetes no slo en el mbito TCP, sino tambin en el IP, red, y aplicacin (para aplicaciones comunes). Es una herramienta imprescindible para cualquier administrador de sistemas, aunque no aparezca en las distribuciones de las diferentes variantes de UNIX. El cdigo es de libre distribucin. Sus autores son Van Jacobson, Craig Leres y Steven McCanne, de la Universidad de California, aunque el programa en que se basaba el original, el Etherfind, era propiedad de Sun Microsystems y se distribua dentro de SunOS. A continuacin, se indican los resultados que puede mostrar el programa tcpdump. 3) El programa tcpdump El programa tcpdump permite capturar y filtrar paquetes que cruzan una interfaz de red que se ha activado en modo promiscuo (todos los paquetes que pasan por el medio son capturados y filtrados). Los paquetes son procesados por un software especial que slo puede ejecutar el superusuario (root) de la mquina. Para ver cmo funcionan los diferentes protocolos, proporcionamos ejemplos de las trazas que muestra el tcpdump durante el establecimiento o la terminacin de la conexin.
Ms informacin En los sistemas UNIX podris encontrar ms informacin utilizando el comando man. Por ejemplo, para saber ms detalles del comando route de UNIX podis ejecutar: $ man route En MSWindows, podis obtener ms informacin de algunos comandos aadiendo /? como argumento: C:> route /?
Derechos de acceso Todos los comandos que se muestran dentro de este anexo estn parcial o totalmente limitados a ser utilizados por todos los usuarios a excepcin del superusuario (root en UNIX o Administrator en MSWindowsNT). MSWindows95/98 es menos escrupoloso en este aspecto.
Nota En LAN, el tcpdump pone la tarjeta de red en modo promiscuo. Lo que significa que todo el trfico de la red es visible, con lo que cualquier usuario malintencionado (un hacker) puede hacer un mal uso del mismo. Por tanto, el tcpdump y otras herramientas similares o derivadas del tcpdump, conocidas como detectores (sniffers) se pueden considerar como una herramienta potencialmente peligrosa. De hecho, lo que es arriesgado es no utilizar al menos uno de los tres mecanismos de proteccin ms importantes contra los detectores: cifrado, cifrado y cifrado.
FUOC P07/89013/00291
42
Para ver cmo funciona este comando, puede utilizarse la instruccin man de UNIX (o LINUX). En este anexo ofrecemos un ejemplo del significado de la traza del tcpdump. El formato general de salida del tcpdump es el siguiente: Data src> dst: flag data-sqno ack window urgent options El significado de los componentes del formato son los siguientes: data: este componente nos proporciona la hora en que se produjo el acontecimiento en formato hora:minutos:segundos.microsegundos (o milisegundos, segn la resolucin del reloj). src y dst: son las direcciones IP y los puertos TCP/UDP de las conexiones de fuente y de destino. flags: son una combinacin de los posibles indicadores de un segmento/datagrama TCP/UDP: S (SYN), F (FIN), P (PUSH), R (RST) y . (que significa que no hay indicadores). data-sqno: describe el nmero de secuencia de la porcin de datos. ack: es el nmero de secuencia del byte siguiente que espera recibir el otro extremo TCP/UDP. window: es el tamao de la ventana que el receptor advierte al transmisor. urgent: indica que existen datos urgentes en este segmento/datagrama. options: son las opciones TCP que suelen estar entre corchetes del tipo < >; por ejemplo, el tamao mximo del segmento (por ejemplo, <mss 1.024>). Un ejemplo de una lnea que retorna el comando tcpdump sera el siguiente: supongamos que hacemos un rlogin desde la mquina argos (fuente) hasta la mquina helios (destino). El comando tcpdump podra devolvernos lo siguiente: 12:34:23.165439 argos.1023 > helios.login: S 7838437: 7838437 (0) win 4096 <mss 1024> 12:34:23.165439 helios.login > argos.1023: S 453534: 453534 (0) ack7838438 win 4096 <mss 1024> La primera lnea indica lo siguiente: a) El acontecimiento tiene lugar a las 12:34:23.165439. b) Su origen es la mquina argos con el puerto 1.024. Su destino es la mquina helios con el puerto login. c) El indicador S seala que es un segmento de SYN (por ejemplo, por un inicio de conexin). d) Advierte un nmero de secuencia 7.838.437 y consume hasta este nmero. Conviene observar que el tcpdump escribe el nmero inicial y el final del nmero de secuencia de datos, y, entre parntesis, la diferencia indicando la longitud del campo de datos (en este caso 0 bytes, puesto que es un segmento de peticin de conexin). Por tanto, indica entre parntesis la longitud del segmento de datos. Este nmero de secuencia es absoluto. Las salidas siguientes del tcpdump indicarn los nmeros de secuecia relativos al inicial. Por ejemplo, en lugar de indicar 7.838.437: 7.838.450, (13) en notacin absoluta, indicar 1:13, (13) en notacin relativa al ISN (se cumple que valor absoluto es igual al ISN ms el valor relativo). Lo mismo se aplica a los nmeros de secuencia del ACK. e) Advierte una ventana de 4.096 bytes. f) Hay una peticin de tamao mximo de segmento de 1.024 bytes. La segunda lnea indica lo siguiente: a) El origen es la mquina helios con el puerto login. El destino es la mquina argos con el puerto 1.023. b) El indicador S seala que es un segmento de SYN (por ejemplo, para un inicio de conexin).
FUOC P07/89013/00291
43
c) Indica el nmero de secuencia inicial 453.534. d) Reconoce con un ACK el byte siguiente que espera del transmisor, el 7.838.438 (es decir, 7.838.437 + 1), puesto que los recibi correctamente hasta el 7.838.437). e) Advierte una ventana de 4.096 bytes. f) Hay una peticin de tamao mximo de segmento de 1.024 bytes. El programa tcpdump permite escuchar, de manera sencilla, todo lo que sucede en la red. Admite toda una serie de indicadores para filtrar slo las direcciones IP de fuente o de destino que pueden interesar, o el tipo de protocolo que se quiere escuchar (TCP, UDP, ARP, etc.). Asimismo, admite indicadores para obtener el campo de datos, para filtrar un nmero fijo de segmentos, etc. Para ver todas las posibles opciones que permite el programa tcpdump se utiliza el comando man.
FUOC P07/89013/00291
44
Anexo 2 El algoritmo checksum

Los protocolos IP y TCP utilizan, entre otros, un sencillo checksum para la deteccin de errores. sta es una versin del algoritmo checksum:
u_short checksum(u_short * addr,int len) { int aux_len = len; u_short *aux_addr = addr; u_short res; int sum = 0; while(aux_len > 1) { sum+ = *aux_addr++; aux_len- = 2; } if(aux_len == 1) sum+ = *(u_char) *aux_addr; sum = (sum>>16) + (sum & 0xffff); sum+ = (sum>>16); res = ~sum; return res; }

Protocolos de La Capa de Transporte

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Protocolos de La Capa de Transporte

Загружено:

Авторское право:

Доступные форматы

Protocolos de transporte

Jos M. Barcel Ordinas Jordi igo Griera

1. Protocolos del nivel de transporte

La figura siguiente ilustra la situacin de los protocolos de transporte en la pila TCP/IP.

2. El UDP (user datagram protocol)

3. El TCP (transmission control protocol)

a) El campo Puerto de origen identifica la aplicacin en el terminal de origen.

b) El campo Puerto de destino identifica la aplicacin en el terminal de destino.

FIN: indica que el transmisor ha acabado la conexin.

RST: realiza un reset de la conexin.

CWR: estos dos bits se utilizan si se implementa un control de congestin.

i) El campo Checksum se utiliza para detectar errores.

* MSS es la sigla de maximum segment size.

3.6. Diagrama de estados del TCP

Consultad el MSL en el subapartado 3.5 de este mdulo didctico.

* RTT es la sigla de round trip time.

Algoritmo congestion avoidance

El transmisor enva datos de acuerdo con el algoritmo slow start.

threshold = mx(2 MSS, (ventana de congestin) / 2)

Anexo 2 El algoritmo checksum

Вам также может понравиться