05-tcp-book and practs (spanish)

Jose L. MuozJuanjo Alins

Jorge MataOscar Esparza

UPC Telematics Department

Transmission Control Protocol

ndice general

1. Transmission Control Protocol 51.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2. Puertos y Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3. Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4. User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5. Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5.1. Protocolos de Ventana Deslizante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.2. TCP y la ventana deslizante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.3. El segmento TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5.4. Establecimiento y cierre de una conexin TCP . . . . . . . . . . . . . . . . . . . . . . . . . 121.5.5. Transferencia de informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5.6. RTT y Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.6. Clculo del checksum de UDP y TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.7. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.7.1. Ejemplo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.7.2. Ejemplo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.8. Prcticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.8.1. Transicin de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.8.2. Anlisis de trfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Captulo 1

Transmission Control Protocol

1.1. IntroduccinDos de los protocolos de transporte estandarizados en la torre TCP/IP son TCP (Transmission Control Protocol) y

UDP (User Datagram Protocol). Previamente a describir TCP y UDP, veremos una clasificacin de los protocolos encuanto a cmo establecen la conexin y a su fiabilidad.

Un protocolo puede clasificarse en funcin de cmo realiza la conexin en:

Orientado a conexin. En este caso, para realizar un intercambio de informacin entre dos entidades se puedendistinguir las siguientes fases:

1. Establecimiento de la conexin

2. Intercambio de informacin

3. Cierre de la conexin

Una de las caractersticas de un servicio orientado a conexin es que una vez establecida la conexin, losmensajes llegan al receptor en el mismo orden en que fueron enviados por el emisor.

Un ejemplo de este procedimiento es la comunicacin a travs del telfono:

1. Establecimiento de la conexin: La persona llamante, inicia el establecimiento de la conexin descolgandoel telfono y marcando el nmero del abonado llamado. El abonado llamado descuelga el telfono y laconexin ya est realizada.

2. Intercambio de informacin: Ambos abonados, llamante y llamado, conversan a travs del telfono.

3. Cierre de la conexin: Los abonados cuelgan el telfono dando por finalizada la llamada.

No orientado a conexin. En este caso, el intercambio de informacin no necesita de las fases de establecimiento ycierre de la conexin. La entidad transmisora enva el mensaje sin que la receptora sepa que va a recibir esemensaje.

Un ejemplo de un servicio no orientado a conexin es el sistema postal. En este caso, el remitente enva unacarta al destinatario. El destinatario sabe que el remitente le envi una carta en el momento en que la recibe.

Otro parmetro que se utiliza para clasificar un protocolo es la fiabilidad del protocolo en cuanto a la entrega de lainformacin.

Se dice que un protocolo es fiable cuando implementa los mecanismos necesarios para que la informacin quetransporta llegue al otro extremo libre de errores. Se dice que un protocolo es no fiable si no nos asegura la entrega delos mensajes al extremo receptor.

Como ejemplo, Internet Protocol (IP) es un protocolo no orientado a conexin y no fiable. Es no orientado aconexin porque un datagrama IP se entrega a la red sin un establecimiento previo de la conexin y es no fiable porque

5

no incorpora ningn mecanismo que nos informe de si el datagrama ha sido entregado al extremo receptor con xito osi no ha podido ser entregado.

Dado que IP es un protocolo no orientado a conexin, no fiable, los protocolos que estn por encima de IP (Nivelde Transporte) se van a tener que enfrentar con las siguientes situaciones de error:

1. Prdida de una trama

2. Llegada de una trama fuera de orden

3. Duplicacin de una trama

4. Modificacin de los datos de la trama

TCP (Transmission Control Protocol) es un protocolo orientado a conexin y fiable. Esto nos indica que TCP va atener que resolver las cuatro posibles situaciones de error que hemos visto para proporcionar un servicio orientado aconexin y fiable, a sus propios usuarios (por usuarios se entiende aquellos protocolos o aplicaciones que utilicen TCPcomo protocolo de transporte).

UDP (User Datagram Protocol) es un protocolo no orientado a conexin y no fiable. Si una aplicacin desea unservicio fiable, o bien utiliza TCP o si utiliza UDP deber ser la aplicacin quien implemente los mecanismos defiabilidad.

Obsrvese que el uso de TCP o UDP depender de varios aspectos. Entre ellos, y adems de la fiabilidad, laeficiencia:

Supongamos que vamos a realizar una conferencia telefnica durante la que estaremos hablando 10 min-utos. El tiempo invertido en marcar el telfono del abonado llamado y que ste descuelgue es de 30segundos y el tiempo de "liberar la llamada" (despedirse y colgar el telfono) de 5 segundos. El tiempototal invertido para completar toda la llamada ser de 10*60+30+5=635 segundos y el tiempo invertidoen el intercambio de informacin son 600 segundos. La eficiencia obtenida es de 600/635, 94.5 %. Si eltiempo invertido en el intercambio de informacin hubiese sido de 5 segundos (decir solo una palabra) laeficiencia hubiera bajado al 12.5 %.

Un protocolo orientado a conexin (como TCP) utiliza un cierto tiempo en establecer y liberar la conexin.La fiabilidad de un protocolo puede ser un factor determinante, pero no siempre. Cuando se transmite voz, es ms

importante que las muestras de voz estn disponibles en los instantes requeridos en el receptor, que el hecho de quehaya alguna muestra errnea, perdida o duplicada. Por esta razn, la mayora de sistemas de transmisin multimediasobre IP utilizan el protocolo UDP.

Un ejemplo de protocolo no orientado a conexin y no fiable es el sistema postal de correos. En estesistema el remitente escribe una carta que posteriormente encapsula (introduce) en un sobre con ladireccin del destinatario. Dicho sobre se entrega al servicio postal de correos, cuya misin es hacer llegarel sobre a la direccin del destinatario. El destinatario, a priori, no sabe que el remitente ha entregado elsobre al servicio postal de correos. Si durante el tranporte del sobre, ste se pierde, ni el destinatario, ni elremitente sern informados de este hecho (no fiable).

Si el remitente desea enviar otra carta al mismo destinatario, debera introducirla de nuevo en un sobrecon la direccin pertinente y entregarlo al servicio postal de correos. Si el transporte de este segundo sobrese realiza de forma ms rpida que el primero (por ejemplo por avin), es posible que los sobres (y lascartas) lleguen desordenados (problema inherente a un servicio no orientado a conexin).

Una de las caractersticas de un servicio no orientado a conexin es que las unidades de datos (los sobres) se manejande forma independiente aunque la informacin transportada (las cartas) formen parte de una misma comunicacin. Poresta razn, cada sobre debe llevar la direccin del destinatario. Observese que en el ejemplo de la llamada telefnica(servicio orientado a conexin), la direccin (nmero de telfono del abonado receptor) slo se proporciona en elestablecimiento de la conexin.

No es difcil notar, que a pesar de tener un servicio no orientado a conexin y no fiable, nosotros (el escritor decartas) puede utilizar mecanismos para obtener, finalmente, un servicio fiable. Estos mecanismos seran:

6

1. Para solucionar el problema de la fiabilidad, el remitente de la carta incluye una postdata pidiendo al destinatariouna confirmacin antes de 14 das. El remitente est suponiendo que en el peor de los casos, el servicio postalde correos no tardar ms de 7 das en entregar la carta al remintente y 7 das ms en recibir la confirmacin. Sien 14 das no ha recibido confirmacin puede suponer que la carta que envo o la confirmacin se ha perdido.En este caso vuelve a enviar la carta.

2. Para solucionar el problema de ordenamiento, las cartas se numeran de forma consecutiva. De esta forma elremitente sabe leerlas de forma ordenada o bien detectar qu carta se ha perdido.

Finalmente, el siguiente ejemplo, muestra un servicio no orientado a conexin y fiable. Este caso es el de las empresasde transporte de paquetes (estilo packet express). Se deja como ejercicio al lector determinar porque es un serviciono orientado a conexin y fiable.

1.2. Puertos y SocketsPara explicar qu son los puertos y los sockets lo realizaremos a travs de un ejemplo. Supongamos que tenemos en

un misma mquina (Maq-A) varios procesos comunicndose simultneamente con otros tantos procesos en diversasmaquinas (Maq-B, Maq-C ...). Cada vez que un datagrama IP llega a Maq-A, el nivel IP extrae la informacin y la pasaal nivel de transporte (UDP TCP). El nivel de transporte, realizar las funciones especficas segn sea UDP o TCPy posteriormente debe entregar la informacin al proceso al cual va dirigida. El nivel de transporte en la torre TCP/IP,utiliza el concepto de puerto para demultiplexar la informacin recibida y entregarla a la aplicacin correspondiente.El puerto es un nmero de 16 bits sin signo (0-65535) que se asigna a un proceso que quiere comunicarse a travs deTCP/IP y ese nmero de puerto va encapsulado en los paquetes TCP y UDP. La Figura 1.1 muestra un ejemplo de loque se acaba de describir.

Un socket1 identifica de forma univoca una conexin entre dos procesos en TCP/IP. Refirindonos a la Figura 1.1,la conexin entre los procesos a y a est identificada por el socket (IP1, P1, IP2, P4), es decir, direccin IP y puertode origen y direccin IP y puerto de destino. Obsrvese que el nmero de puerto es local a la mquina; as dos procesosen mquinas diferentes pueden tener el mismo nmero de puerto.

TCP/IP TCP/IP TCP/IP TCP/IP

a a

b

bc c

IP1 IP2 IP3 IP4

P1P2

P3 P4 P1 P8

Figura 1.1: Puertos y sockets

1.3. Arquitectura cliente-servidorEn el mundo de TCP/IP las comunicaciones entre procesos siguen una arquitectura denominada cliente-servidor.

La idea es que un proceso acta como un servidor (proporciona servicios a los clientes) y espera que algn clientese conecte a l en demanda de un servicio. Otro proceso acta como cliente y se conecta al servidor para obtener unservicio.

1La palabra socket se utiliza con acepciones diferentes segn el entorno. Cuando se habla del protocolo TCP/IP, la definicin es la que se hadado. Si se est hablando del API de programacin de TCP/IP su significado es diferente.

7

Servidor Cliente

Esperarpeticion

Procesarpeticion

Enviarresultado

Enviarpeticion

Recibirresultado

Inicio

Fin

Figura 1.2: Arquitectura Cliente Servidor

Un ejemplo del funcionamiento es la conexin desde un navegador a un servidor de WEB. El servidor de WEBdebe estar esperando que algn navegador se conecte a l con el fin de proporcionar una pagina HTML. Desdeel punto de vista del usuario, primero arranca el navegador, luego se realiza la conexin y cuando el usuario se hacansado de navegar, cierra el navegador, mientras que el servidor de WEB contina esperando otras conexiones.La Figura 1.2 muestra el flujograma que describe este comportamiento.

De esta arquitectura se deduce que un cliente debe conocer la IP y el puerto del servidor. Siguiendo con el ejemplodel navegador, si el usuario introduce la URL http://www.upc.es, el navegador se conectar al puerto 80. Esto esdebido a que hay una serie de puertos conocidos con el nombre de well known ports en los que se aconseja qutipo de servicio deben proporcionar. As el puerto 21 es para el servidor de ftp, 23 es para el servidor de telnet, el25 para el servidor de SMTP (servicio de correo electrnico), el 80 para el servidor de http, etc. Esto no significaque todos los servidores WEB escuchen en el puerto 80, ya que es potestad del administrador del sistema decidirqu puerto utilizar su servidor WEB. Sin embargo, la mayora de clientes tienen establecido un puerto por defectopara el servidor (como en el caso del navegador y el puerto 80), de forma que si se cambia el puerto de un serviciobien definido, solo se lograr confundir al cliente (tanto el cliente software como al usuario que est utilizando esecliente). A modo de ejemplo, si se desea utilizar un navegador para conectarnos a un puerto diferente del de defecto(por ejemplo el 8080), la forma de introducir la URL es http://nombre_servidor:8080. Si el servidor de WEB de laUPC estuviese en el puerto 8080, la URL sera http://www.upc.es:8080.

1.4. User Datagram Protocol

Tal como se ha comentado UDP (User Datagram Protocol) es un protocolo no orientado a conexin y no fiable.La especificacin oficial de UDP se encuentra en el RFC768.

El formato y los campos de un datagrama UDP se muestran en la Figura 1.3.El campo de longitud se refiere a la longitud total, en bytes, de la cabecera y los datos. La aplicacin que utiliza

UDP, debe controlar el tamao del paquete UDP (la cantidad de bytes enviados en un mismo paquete UDP) si quiereevitar que el nivel IP fragmente el paquete UDP porque se ha excedido el MTU (Maximum Transmission Unit) delmedio fsico. Por ejemplo, si el medio fsico es una Ethernet con tramas Ethernet II, el campo de datos de la tramaEthernet tiene una longitud mxima de 1500 bytes. En este caso, la longitud mxima del datagrama IP encapsuladoen una trama Ethernet sera de 1500 bytes. Si utilizamos UDP como protocolo de transporte, la cantidad de bytes deusuario (campo data del datagrama UDP) ser como mximo 1500 20 8 = 1472 bytes (a 1500 se le resta lacabecera IP, usualmente 20 bytes, y la cabecera UDP, 8 bytes)

El clculo del checksum se especifica en la seccin 1.6. El checksum incluye tanto la cabecera UDP como el campo

8

0 15 16 31

16-bit source port number

16-bit UDP checksum

data (if any)

8 by

tes16-bit destination port number

16-bit UDP length

Figura 1.3: Datagrama UDP

de datos, (recordemos que el checksum de la cabecera de IP solo incluye la cabecera IP y no los datos del datagramaIP). En UDP el el clculo del checksum es opcional. Si el emisor no realiza el clculo del checksum, enva este campocon ceros. Si el emisor realiza el clculo del checksum y obtiene un valor 0, envia todo unos (65535) que es equivalenteen aritmtica de complemento a uno. Si el emisor calcula el checksum y el receptor detecta un checksum errneo, eldatagrama UDP se descarta silenciosamente (esta condicin de error no se indica ni al emisor ni a los protocolos denivel superior del receptor).

1.5. Transmission Control ProtocolTCP es un protocolo orientado a conexin, fiable. Especficamente, se dice que TCP proporciona un servicio de

transporte de un flujo de bytes, orientado a conexin, fiable.El concepto de transporte de un flujo de bytes, indica que la aplicacin entrega a TCP los bytes que desea transmitir

y que TCP no interpretar esos bytes, nicamente los har llegar a la aplicacin receptora en el orden en que se losentregaron. En otras palabras, si una aplicacin entrega 20 bytes a TCP, seguido de una entrega de 30 bytes, seguidode una entrega de 60 bytes, la aplicacin receptora no sabe cuntas entregas se hicieron al TCP, sino que puede ocurrirque al leer los bytes recibidos, lo haga en cinco lecturas de 22 bytes.

TCP proporciona fiabilidad utilizando los siguientes mecanismos:

Los datos de la aplicacin son fragmentados en lo que TCP considera que es el mejor tamao para ser transmi-tidos.

Cuando TCP enva un segmento, inicia un temporizador, esperando que el otro extremo reconozca la recepcincorrecta del segmento enviado. Si el reconocimiento no ha sido recibido cuando el temporizador ya ha expirado,el extremo transmisor vuelve a enviar el mismo segmento.

Cuando TCP recibe un segmento de datos, enva un reconocimiento al extremo que lo ha enviado2.

TCP incluye un checksum de la cabecera y los datos cuyo propsito es detectar cualquier modificacin de losdatos en trnsito. Si el checksum recibido es incorrecto, el segmento TCP se descarta silenciosamente y no sereconoce. Se espera que el temporizador del TCP del extremo opuesto expire y se lo vuelva a enviar.

Dado que los segmentos TCP viajan encapsulados en datagramas IP, y dado que los datagramas IP puedenllegar desordenados, los segmentos TCP pueden llegar desordenados. El TCP del extremo receptor reordena, sies necesario, los segmentos recibidos y entrega, a la aplicacin, los datos en el orden correcto.

Dado que los datagramas IP pueden llegar duplicados, TCP debe descartar los segmentos TCP duplicados.

TCP tambin proporciona control de flujo. Los extremos TCP tienen una cantidad finita de espacio de almace-namiento. El extremo TCP receptor indica al extremo TCP emisor cunto espacio de almacenamiento tiene paralos datos recibidos. De esta forma se previene que un ordenador cuyo ritmo de generacin de datos es alto puedasuperar la capacidad de recibir y procesar datos del ordenador receptor.

El sistema que utiliza TCP para proporcionar fiabilidad se engloba en los llamados protocolos de ventana deslizante.2Este reconocimiento se denomina ACK (acknowledge).

9

1.5.1. Protocolos de Ventana Deslizante

La pregunta que nos hacemos es, cmo puede un protocolo proporcionar un servicio de transferencia fiablesobre un sistema de comunicaciones no fiable?. Una de las tcnicas ms utilizadas es el ARQ (Automatic RepeatRequest) o peticin de retransmisin automtica. En ARQ, el receptor informa al emisor del xito o fracaso de la ltimatransmisin, a travs de una trama de reconocimiento. Los reconocimientos pueden ser positivos (reconocimiento dexito) y negativos (reconocimiento de errores en la trama recibida). No todos los protocolos utilizan simultneamenteambos tipos de reconocimiento. Por ejemplo TCP slo utiliza reconocimientos positivos y cuando hay errores no envanada, utilizando temporizadores para las retransmisiones.

En la Figura 1.4 se muestra la transmisin de dos tramas con reconocimiento. Este sistema se conoce con elnombre de Stop & Wait porque despus de enviar un paquete, el emisor debe parar de transmitir y esperar la recepcindel reconocimiento. Obsrvese que el tiempo efectivo utilizado para transmitir una trama es desde el inicio de latransmisin de la trama hasta que se recibe el reconocimiento. En este caso la eficiencia de transmisin es baja, puestoque el hecho de que el emisor deba esperar el reconocimiento le imposibilita para seguir transmitiendo.

Emisor ReceptorPaquete1

Paquete2

ack1

ack2

ttransmision

Figura 1.4: Stop & Wait

Supongamos que modificamos el algoritmo de manera que el emisor pueda tener como mximo F tramas noreconocidas. El emisor podr enviar como mximo F tramas sin recibir reconocimiento de ellas. F se denomina eltamao de la ventana y en cuanto reciba el reconocimiento de la primera trama (ACK(1)), podr enviar una nuevatrama, y as sucesivamente. Este es el caso representado en la Figura 1.5, para un tamao de ventana F = 6.

El hecho de utilizar ventana deslizante implica que las tramas de informacin deben ir numeradas para que losreconocimientos indiquen mediante este nmero qu trama ha sido recibida correcta o incorrectamente.

Es importante destacar que en un sistema de ventana deslizante, no es necesario enviar una trama de reconocimientopor cada trama de datos. Se puede reconocer con una sola trama de reconocimiento varias tramas de datos teniendoen cuenta que si se han enviado 3 tramas de datos y se reconoce la trama 3, entonces, de forma automtica, quedanreconocidas la 1 y la 2.

Es habitual que en una comunicacin entre dos ordenadores, cada uno de ellos acte simultneamente de emisory receptor, ya que la informacin suele fluir tanto en un sentido como en el otro. Para aumentar la eficiencia, elpaquete de informacin incluye un campo utilizado para reconocimiento, evitndose el tener que enviar tramas dereconocimiento y de informacin diferentes cuando ambas tramas viajan en el mismo sentido. A esta tcnica se leconoce con el nombre de piggybacking.

1.5.2. TCP y la ventana deslizante

TCP utiliza un mecanismo especializado de ventana deslizante con objeto de mejorar la eficiencia de transmisiny realizar un control de flujo.

Como se ha comentado anteriormente, TCP ve los datos de usuario como un flujo de bytes que divide en segmentospara ser transmitidos. Por esta razn TCP no numera los segmentos sino los octetos transmitidos y a su vez, losreconocimientos reconocen octetos recibidos y no segmentos recibidos.

10

1 2 3 4 5 6 7 8 9 10

Ventana inicial

1 2 3 4 5 6 7 8 9 10

La ventana desliza

Envio Paquete1Envio Paquete2Envio Paquete3

Recibo ACK1Recibo ACK2Recibo ACK3

EMISOR RECEPTOR

Recibo Paquete1/Envio ACK1



Enviados, noreconocidos

1 2 3 4 5 6 7 8 9 10

Ventana actual

11

Enviados yreconocidos

Se puedenenviar No se pueden

enviar hasta quela ventana se mueva

Figura 1.5: Ventana Deslizante

En TCP el tamao de ventana indica el nmero de octetos que pueden ser recibidos y el receptor indica al emisor,en cada trama enviada, qu tamao de ventana tiene disponible para recibir el siguiente segmento, realizando, de estamanera, el control de flujo. Si se indica un tamao de ventana 0, el emisor deja de enviar segmentos hasta que recibeotro paquete indicando un tamao de ventana distinto de 0.

1.5.3. El segmento TCPLa Figura 1.6 muestra cmo es el segmento TCP.

0 15 16 31

hdr len

16-bit destination port number

16-bit window size

16-bit TCP checksum

32-bit sequence number

32-bit acknowledge number

options (if any)

data (if any)

20 b

ytes


URG

ACK

PSH

RST

SYN

FIN

16-bit urgent pointer

Figura 1.6: Segmento TCP

Los primeros 32 bits indican los puertos origen y destino. Los siguientes 32 bits son el nmero de secuencia. Elnmero de secuencia identifica el byte del flujo de datos que est siendo enviado y que ocupa la primera posicin en elcampo de datos del segmento. El primer byte de un flujo en un segmento TCP no lleva el nmero 1 como nmero de

11

secuencia, sino que se elige un nmero aleatorio (Inital Sequence Number) en cada conexin realizada y este nmerorepresenta el nmero de secuencia del primer byte a transmitir durante esa conexin. Si el ISN de una conexin esel 1415531521, el primer byte estara identificado por este mismo nmero y el segundo sera 1415531521 + 1, yas sucesivamente. De esta forma si un segmento TCP llega a una conexin equivocada (cosa bastante inverosmil),los nmeros de secuencia de ambas conexiones no podran a llegar a confundirse nunca, ya que ambas conexionesutilizaron un ISN muy diferente y los datos que llegaron a la conexin equivocada nunca sern pasados a la aplicacinequivocada (el TCP generara un error al recibir un nmero de secuencia no esperado).

El campo del nmero de reconocimiento (acknowledge number) se utiliza para almacenar el nmero del siguientebyte que se espera recibir. Este campo slo se decodifica si el flag ACK est activado. Si se recibi un paquete de datoscon el nmero de secuencia 1415531521 y con 100 bytes de datos (desde el 1415531521 hasta el 1415531620), elsegmento TCP de respuesta llevara activado el flag ACK y el nmero de reconocimiento sera el 1415531621, puestoque espera recibir el siguiente al 1415531620.

El campo hdr len (Header Length) indica la longitud de la cabecera que puede llevar opciones haciendo que lalongitud de la cabecera vare.

A continuacin vienen 6 bits reservados (no se utilizan) y 6 bits que actan de flags:

urg: Urgent Pointer vlido

ack: Nmero de reconocimiento vlido

psh: Segmento con datos de usuario. Pasarlos a la aplicacin tan pronto como sea posible.

rst: Reinicio de la conexin

syn: Inicio de conexin

fin: Final de conexin

El campo window size es de 16 bits e indica el tamao de ventana en bytes. Los 16 bits siguientes se utilizan para elchecksum y los siguientes 16 bits para indicar un urgent pointer (el urgent pointer se explicar en la seccin 1.5.5).

Existen varias opciones en TCP, y la ms utilizada es el MSS (Maximum Segment Size). Cada extremo de unaconexin indica al otro cul es el tamao mximo de segmento que desea recibir. Este valor se especifica dentro delcampo de opciones al inicio de la conexin.

1.5.4. Establecimiento y cierre de una conexin TCPEstablecimiento de la conexin

El proceso que abre una conexin, lo hace enviando un segmento TCP con el flag SYN activado y un nmerode secuencia (ISN) que identificar los bytes transmitidos. No se transmiten datos de usuario. El flag ACK no estactivado porque todava no hay bytes que reconocer.

El proceso que recibe este segmento, contesta con un segmento TCP con el flag SYN activado, un nmero desecuencia aleatorio, el flag ACK activado y el nmero de reconocimiento igual al ISN recibido ms uno (se suponeque un segmento SYN consume un byte).

El proceso que inici la conexin responde al segmento recibido con un segmento con el flag ACK activado y elnmero de secuencia de reconocimiento igual al nmero de secuencia recibido ms uno.

En este momento ya est establecida la conexin. Esta apertura de conexin se conoce con el nombre de establec-imiento de conexin a tres bandas, porque se utilizan tres segmentos. La Figura 1.7 muestra el establecimiento deuna conexin TCP.

Timeout en el establecimiento de la conexin

Puede ocurrir que el extremo remoto no responda al segmento SYN de apertura de conexin. En ese caso sereintenta la apertura de la conexin varias veces. Por ejemplo, en un S.O. Linux con un kernel 2.4.10, el resultadoobtenido al intentar establecer una conexin fue:

12

SYN 1415531521 win 4096

SYN 1823083521 ACK 1415531522 win 4096

ACK 1823083522 win 4096

Est

able

cim

ient

o de

la c

onex

ion

EMISOR RECEPTOR

Figura 1.7: Establecimiento de la conexin

No Time Source Destination Prot Info

1 0.000000 192.168.69.5 192.168.69.19 TCP 32773 > 23 {[}SYN]

Seq=4209576593 Ack=0 Win=5840

2 2.990898 192.168.69.5 192.168.69.19 TCP 32773 > 23 {[}SYN]

Seq=4209576593 Ack=0 Win=5840

3 8.990899 192.168.69.5 192.168.69.19 TCP 32773 > 23 {[}SYN]

Seq=4209576593 Ack=0 Win=5840

4 20.990900 192.168.69.5 192.168.69.19 TCP 32773 > 23 {[}SYN]

Seq=4209576593 Ack=0 Win=5840

5 44.990899 192.168.69.5 192.168.69.19 TCP 32773 > 23 {[}SYN]

Seq=4209576593 Ack=0 Win=5840

6 92.990900 192.168.69.5 192.168.69.19 TCP 32773 > 23 {[}SYN]

Seq=4209576593 Ack=0 Win=5840

El tiempo de espera entre intentos de conexin es de la forma 3 2n, n = 0, . . . , 4. El nmero de reintentos antes dedecidir que la conexin no se puede realizar se controla a travs de la variable /proc/sys/net/ipv4/tcp_syn_retries cuyovalor durante la prueba realizada era de 5.

Maximum Segment Size (MSS)

Una de las opciones que se incluyen en los segmentos SYN es el Maximum Segment Size. Cada uno de los extremosinforma al otro del tamao mximo de segmento que desea recibir. Como regla general, cuanto mayor sea el MSS, sinque se produzca fragmentacin a nivel IP, mayor ser la eficiencia ya que se amortiza las cabeceras de IP y TCP. Si elnivel fsico es Ethernet con tramas Ethernet II, el mayor datagrama IP ser de 1500 bytes. Si restamos la longitud delas cabeceras IP y TCP tendremos el MSS: 1500 20 20 = 1460 bytes. Si se utiliza un encapsulado IEEE 802.3entonces el MSS tendra un valor de 1452 bytes.

13

Cierre de una conexin TCP.

El cierre de una conexin se realiza mediante segmentos TCP con el flag FIN activado. El cierre de una conexinTCP utiliza 4 segmentos. Esto es debido a que una conexin TCP es full-duplex, y cada una de las direcciones debeser cerrada independientemente de la otra. La Figura 1.8 muestra el cierre de una conexin TCP.

FIN 1415531522 ACK 1823083522 win 4096

ACK 1415531523 win 4096

FIN 1823083522 ACK 1415531523 win 4096

ACK 1823083523 win 4096

Cie

rre

de la

con

exio

n

EMISOR RECEPTOR

Figura 1.8: Cierre de una conexin TCP

La idea en un cierre de conexin TCP es que cualquiera de los extremos que haya enviado todos los datos puederealizar un cierre de su conexin (half-close), mientras que puede seguir recibiendo datos del extremo remoto.

Diagrama de transicin de estados de TCP

La Figura 1.9 muestra el diagrama de transicin de estados de TCP. Algunos estados son especficos del servidormientras que otros lo son del cliente. Por ejemplo, como se ha comentado en la seccin 1.3, un servidor puede estaresperando que los clientes se conecten a l. La espera corresponde a un estado de LISTEN. En realidad se diceque el servidor est escuchando, en un puerto, nuevas conexiones. Cuando se ejecuta un servidor pasa de estadoCLOSED a estado LISTEN esperando que le lleguen segmentos TCP con el flag SYN activado (establecimiento deconexin). Sin embargo, cuando se ejecuta un cliente, ste iniciar directamente la conexin con el servidor envindoleun segmento SYN.

La Figura 1.10 es un ejemplo de los estados y los segmentos del cliente y servidor en la fase de establecimiento ycierre de la conexin para un modo de operacin normal.

2MSL Timeout

En la Figura 1.9, debajo del estado TIME_WAIT, puede leerse 2MSL timeout. Esto quiere decir que cuando elTCP que realiza un cierre activo (active close) llega al estado TIME_WAIT debe esperar un cierto tiempo antes de darpor finalizada la conexin. Ese tiempo es 2 MSL donde MSL3 (Maximum Segment Lifetime) es el tiempo mximode vida de un segmento. Dado que un segmento TCP viaja encapsulado en un datagrama IP, y ste tiene un campoTTL (time-to-live), un segmento TCP tambin tendr un tiempo de vida en la red.

Por qu el TCP que realiza un cierre activo debe esperar un cierto tiempo?. El cierre de una conexin nunca esuna cosa sencilla, ya que los paquetes de cierre pueden perderse y los extremos TCP pueden quedarse en un estadoincorrecto. Refirindonos a la Figura 1.10, una vez que el cliente ha recibido el segmento FIN, ha pasado al estadoTIME_WAIT y enva un segmento de reconocimiento. Puede suceder que ese segmento de reconocimiento se pierday no llegue nunca a su destino. Si as fuera el caso, el servidor volvera a retransmitir el segmento FIN. Por tanto, elcliente espera un tiempo prudencial (2 MSL) de manera que pueda recibir esa retransmisin del segmento FIN si elreconocimiento se ha perdido.

3El RFC 793 especifica el MSL con una duracin de 2 minutos. Los valores de MSL en diferentes implementaciones es de 30 segundos, 1minuto o 2 minutos.

14

CLOSED

LISTEN

ESTABLISHED

SYN_SENTSYN_RCVD

CLOSE_WAIT

appl: pasive opensend:

passive open

appl: send data

send: SYN

recv: SYN

send: SYN, ACKsimultaneous open

appl:active open

send: SYN

active open

recv: SYN, ACK

send:

ACK

recv: FIN

send: ACK

recv: SYN; send:SYN, ACK

recv: RST

recv: ACKsend:

data transfer state

FIN_WAIT_1

FIN_WAIT_2 TIME_WAIT

CLOSINGrecv: FINsend: ACK

recv: ACKsend:

recv: FIN, ACK

send: ACK

recv: FINsend: ACK

recv: ACKsend:

appl:closesend: FIN

appl:close

send: FIN

LAST_ACK

appl:closesend: FIN

passive close

active close

2MSL timeout

simultaneous close

appl:close

or timeout

recv: ACK

send:

appl:recv:send:

Normal transition from clientNormal transition from serverState transitions taken when application issues operationState transitions taken when segment receivedWhat is sent for this transition

Figura 1.9: Diagrama de transicin de estados de TCP

Un efecto colateral de este estado de espera, es que durante ese tiempo el socket formado por la direccin IP delcliente, puerto del cliente, direccin IP del servidor, puerto del servidor, no puede ser usado para otra conexin. Enrealidad, la propia implementacin del TCP implica que un puerto local que est en un socket en estado TIME_WAITno puede ser usado de nuevo hasta que expire ese estado.

Segmentos RESET

En general, TCP enva un segmento RESET siempre que recibe un segmento que no parece ser correcto para laconexin que tena establecida.

Un caso bien conocido en el que se enva un segmento RESET es cuando se intenta realizar una conexin a unpuerto no activo de un servidor (un puerto no activo significa que no hay ninguna aplicacin que est escuchando enese puerto de ese servidor). En este caso, el servidor responde al segmento SYN con un segmento RST.

15

SYN J

SYN K, ack J+1

ack K+1

FIN M

ack M+1

FIN N

ack N+1

(active open)SYN_SENT

LISTEN(pasive open)

SYN_RCVD

ESTABLISHED

ESTABLISHED

(active close)FIN_WAIT_1 CLOSE_WAIT

(passive close)

LAST_ACK

TIME_WAIT

FIN_WAIT_2

CLOSED

CLIENT SERVER

Figura 1.10: Estados de TCP correspondientes a un establecimiento y cierre de conexin

1.5.5. Transferencia de informacin

El flag PSH

Los segmentos TCP que transportan datos de usuario suelen llevar activado el flag de push (PSH) aunque no esestrictamente necesario. Recordemos que el flag PSH indica que los datos de ese segmento y los datos que hayan sidoalmacenados anteriormente deben ser pasados a la aplicacin receptora lo antes posible. Se puede dar el caso quevarios segmentos que transportan datos no lleven activado el flag PSH; el TCP receptor almacenar esos datos pero nolos entregar a la aplicacin receptora hasta que reciba un segmento con el PSH activado.

Sin embargo, la mayora de implementaciones TCP activan el flag de PSH en cada segmento que transporta datos,hacindolos disponibles a la aplicacin inmediatamente.

El flag URG y el campo Urgent Pointer

El flag URG y el campo Urgent Pointer se utilizan cuando se desea enviar datos que se suponen que no pertenecenal flujo normal de bytes, sino que son datos urgentes. Estos bytes urgentes se insertan en medio del flujo normal debytes, activando el flag URG y estableciendo el campo Urgent Pointer de la cabecera de TCP a un valor que sumadocon el valor del campo de nmero de secuencia de la cabecera de TCP se obtiene el nmero de secuencia del ltimobyte de los datos urgentes.

La especificacin original de TCP no deja claro si el Urgent Pointer debe apuntar al ltimo byte de los datosurgentes o al byte que sigue al ltimo byte urgente. Aunque documentos posteriores aclararon que el Urgent Pointerdebe apuntar al ltimo byte urgente, la mayora de implementaciones de TCP (derivadas de la realizada en Berkeley)continan utilizando la interpretacin equivocada. En Linux es posible indicar en qu forma se desea que funcione elUrgent Pointer variando el valor de la variable /proc/sys/net/ipv4/tcp_stdurg. Si el valor de esta variable es 0 se utilizala interpretacin de Berkeley, si vale 1 se utiliza la interpretacin del estndar.

TCP no especifica mucho ms sobre los datos urgentes, as no hay forma de saber cundo se inician los bytesurgentes en el flujo de datos. Es la aplicacin la que debe saber cmo extraer los datos urgentes.

16

1.5.6. RTT y TimeoutsEn el funcionamiento de TCP y el mecanismo de ventana deslizante (seccin 1.5.2) se indica que TCP realiza un

reconocimiento positivo de los segmentos que ha recibido correctamente. Si el segmento se recibe con errores, el TCPreceptor lo ignora. Al cabo de un cierto tiempo (timeout) el TCP emisor lo retransmite. El clculo del timeout se realizade forma dinmica para cada conexin TCP que se establece ya que las condiciones de transmisin pueden cambiarpor diversas razones, como por ejemplo la congestin de la red o los diferentes caminos seguidos por los datagramasIP para diferentes conexiones remotas.

El clculo del timeout se basa en el clculo del RTT (Round Trip Time). El RTT, definido de forma genrica, es eltiempo que tarda un paquete en ir del emisor hasta el receptor sumado al tiempo que tarda en llegar la confirmacindel receptor al emisor.

TCP calcula el RTT de dos formas diferentes (aunque complementarias):

1. TCP inicia un temporizador cuando se enva un byte (aleatorio) que viaja en un segmento. Cuando TCP recibeel ACK del segmento donde viajaba el byte detiene el temporizador y obtiene el RTT.

2. Una segunda forma de calcular el RTT es a travs de una opcin de TCP, el timestamp. El TCP emisor incluyeuna marca temporal (timestamp) como opcin del TCP. El TCP receptor copia la marca temporal recibida en elsegmento de reconocimiento enviado. De esta forma el TCP emisor puede calcular el RTT de forma ms sencillaque el caso anterior.

El RTT que se utiliza para calcular el tiempo de timeout corresponde a un valor medio obtenido con los diferentesclculos de RTT durante la misma conexin.

El timeout (RTO) se calcula de forma proporcional al RTT4.

1.6. Clculo del checksum de UDP y TCPEl campo de checksum de TCP y UDP cubre tanto la cabecera como los datos (El checksum de la cabecera IP slo

cubre la propia cabecera IP). Para realizar el clculo del checksum, adems de utilizar todo el paquete (TCP UDP)(cabecera + datos), se aade una pseudo-cabecera que incluye la direccin IP fuente, la direccin IP destino, el campode protocolo de la cabecera de IP y la longitud del paquete (TCP UDP). Tal y como se indica en el RFC793, estapseudo-cabecera proporciona proteccin adicional contra paquetes recibidos errneamente por problemas de enrutado.

El checksum es el complemento a uno de 16 bits de la suma en complemento a uno de todas las palabras de 16 bitsde la pseudo-cabecera, cabera y texto del paquete (TCP o UDP).

Si el paquete contiene un nmero impar de octetos, el ltimo octeto del paquete se rellena con ceros por la derechahasta obtener una palabra de 16 bits con propsito de calcular el checksum.

En la Figura 1.11 se muestran los campos utilizados para el clculo del checksum para un segmento TCP.

1.7. Ejemplos

1.7.1. Ejemplo 1El siguiente ejemplo corresponde a una conexin TCP entre las mquinas darkstar (192.168.0.1) y falcon (192.168.0.5).

Aunque TCP permite transmisiones full-duplex, en este caso los datos se transmiten de darkstar a falcon. La capturade las tramas se ha realizado con el programa tcpdump desde darkstar. Cada linea corresponde a una trama transmi-tida. El primer nmero a la izquierda es el nmero de trama, el siguiente es el tiempo relativo a la primera trama ensegundos, el tercer nmero es la diferencia de tiempos entre esa trama y la anterior, a continuacin se indica el hostorigen, puerto origen, host destino, puerto destino con la notacin host_o.puerto_o >host_d.puerto_d:. A continuacinse indican los flags activados S (SYN), F (FIN), P (PSH), R (RST); un punto significa que ninguno de los anterioresest activado. Despus de los flags, se indica el nmero de secuencia del segmento con el formato primero:ltimo(nbytes) que se traduce en nmeros de secuencia primero hasta, pero no incluyendo, ltimo. Por facilidad de lectura,

4Investigaciones ms recientes han derivado en algoritmos ms exactos del calculo del RTT medio, calculando tambin la desviacin media delRTT y ajustando mejor el clculo del RTO.

17

0 15 16 31

hdr len

16-bit destination port number

16-bit window size

16-bit TCP checksum

32-bit sequence number

32-bit acknowledge number

options (if any)

data (if any)


URG

ACK

PSH

RST

SYN

FIN

16-bit urgent pointer

32-bit destination IP address

32-bit source IP address

16-bit segment lengthzero 8-bit protocol

PAD byte (0)

TCPpseudoheader

TCPheader

Figura 1.11: Campos para el clculo del checksum de un segmento TCP

los nmeros de secuencia se presentan de forma completa en los segmentos FIN y posteriormente se presentan relativosa stos. Otros parmetros son el reconocimiento, el tamao de ventana, y las opciones del TCP.

1 0.000000 darkstar.32874 > falcon.7777: S 1485000412:1485000412(0) win 5840

2 0.100321 (0.100321) falcon.7777 > darkstar.32874: S 820456734:820456734(0) ack 1485000413

win 5792

3 0.100434 (0.000113) darkstar.32874 > falcon.7777: . ack 1 win 5840

4 0.100713 (0.000279) darkstar.32874 > falcon.7777: P 1:1025(1024) ack 1 win 5840

5 0.100796 (0.000083) darkstar.32874 > falcon.7777: . 1025:2473(1448) ack 1 win 5840

6 0.201881 (0.101085) falcon.7777 > darkstar.32874: . ack 1025 win 7168


8 0.202031 (0.000043) darkstar.32874 > falcon.7777: FP 3921:5121(1200) ack 1 win 5840



11 0.304583 (0.001126) falcon.7777 > darkstar.32874: F 1:1(0) ack 5122 win 15928


18

En este ejemplo, darkstar, actuando como cliente, inicia una conexin desde el puerto 32874 con falcon al puerto7777 enviando un segmento con el flag SYN activado y nmero de secuencia 1485000412, indicando un tamao deventana de 5840 bytes y en las opciones de TCP indica que desea recibir segmentos de tamao mximo 1460 bytes(ver la seccin 1.5.4) e incluye un timestamp para el clculo del RTT.

falcon responde con un segmento SYN con un reconocimiento que indica que espera recibir un segmento cuyonmero de secuencia sea 1485000413 (recordemos que el flag SYN activado consume un byte). Se puede observaren el campo de opciones del TCP, que falcon ha incluido su propia marca temporal (2997742) y devuelve el valor deltimestamp que recibi en la trama anterior (2997742).

El segmento nmero 3, es el que cierra la fase de establecimiento de conexin a tres bandas. En este casoel nmero de reconocimiento es relativo al indicado en la linea 2. Es decir, que se indica que se espera recibir elsegmento con nmero de secuencia 820456734 + 1.

Los segmentos 4 y 5 muestran cmo darkstar inicia la transferencia de datos con nmeros de secuencia 1485000412+ 1 y 1485000412 + 1025; el segmento 4 tiene el flag PSH activado indicando que desea que la aplicacin receptorapueda acceder a esos datos tan pronto como sea posible.

En el segmento 6 falcon reconoce positivamente los datos recibidos en el segmento nmero 4. El segmento 7transporta 1448 bytes de datos de darkstar a falcon. El segmento 8 transporta 1200 bytes y tiene activados los flags dePSH (indicando que desea que la aplicacin receptora pueda acceder a todos los datos recibidos tan pronto como seaposible) y el flag de FIN indicando que ese segmento inicia el cierre de la conexin.

Los segmentos 9 y 10, enviados desde falcon a darkstar, reconocen que los datos enviados en los segmentos 5 y 7han sido recibidos satisfactoriamente.

En el segmento 11, falcon reconoce la recepcin del segmento 8 y responde al cierre de conexin activando elflag de FIN. Finalmente darkstar reconoce el segmento 12 dando por finalizada la transmisin. Observese que en estecierre se utilizan 3 segmentos (el 8, el 11 y el 12) en lugar de utilizar 4 segmentos tal y como se muestra en la figura1.8

192.168.0.1.32874 192.168.0.5.7777

Syn 1485000412seg. 0

0.000000 (0.000000)

Syn 820456734 Ack 1seg. 1

0.100321 (0.100321)

Ack 1seg. 2

0.100434 (0.000113)

Psh 1:1025(1024) Ack 1 seg. 30.100713 (0.000279)

1025:2473(1448) Ack 1 seg. 40.100796 (0.000083)

Ack 1025 seg. 50.201881 (0.101085)

2473:3921(1448) Ack 1 seg. 60.201988 (0.000107)

Fin Psh 3921:5121(1200) Ack 1 seg. 70.202031 (0.000043)

Ack 2473 seg. 80.204387 (0.002356)

Ack 3921 seg. 90.303457 (0.099070)

Fin 1:1(0) Ack 5122 seg. 100.304583 (0.001126)Ack 2

seg. 110.304634 (0.000051)

Figura 1.12: ICD (Inter Process Communication Diagram) del ejemplo 1

19

1.7.2. Ejemplo 2

En este ejemplo, se ha realizado una conexin entre darkstar y falcon. Sin embargo se ha utilizado un driver parasimular prdidas de paquetes y un retardo medio preestablecido (100 ms).

1 0.000000 darkstar.32872 > falcon.7777: S 4166401040:4166401040(0) win 5840

2 0.100374 (0.100374) falcon.7777 > darkstar.32872: S 3485906442:3485906442(0)

ack 4166401041 win 5792

















19 1.354835 (0.000274) darkstar.32872 > falcon.7777: FP 9041:10241(1200) ack 1 win 5840




23 1.944555 (0.000109) darkstar.32872 > falcon.7777: FP 9041:10241(1200)

24 2.045837 (0.101282) falcon.7777 > darkstar.32872: F 1:1(0) ack 10242 win 21720

20


Los tres primeros segmentos corresponden a la apertura de la conexin. Una vez establecida la conexin darkstarinicia la transmisin de datos en los segmentos 4 y 5, recibiendo un reconocimiento del segmento 4. Darkstar continatransmitiendo datos en los segmentos 7 y 8. El segmento 8 tiene activado el flag PSH. falcon vuelve a reconocer, conel segmento 9, el segmento nmero 4 indicando al emisor que el siguiente (o siguientes) segmento no ha sido recibido.En el segmento nmero 10, darkstar retransmite los datos 1025 al 2472. falcon indica con el segmento 11, que losdatos enviados en el segmento 7 fueron correctamente recibidos, pero no fue as con los datos del segmento 8. Darkstarreenva, en el segmento 12, los datos que se perdiern en el segmento 8 (del 3921 al 5368) y en el segmento 13 envanuevos datos. falcon vuelve a indicar que los ltimos datos recibidos son los del segmento 10 y que espera recibir elbyte 3921 y siguientes. En el segmento nmero 15, darkstar retransmite por tercera vez los bytes 3921 al 5368, queson reconocidos por falcon, junto con los datos enviados en el segmento 13, con el segmento 16. darkstar envia 3nuevos segmentos (17, 18 y 19), activando el flag de cierre de conexin en el ltimo de ellos. Los 6 ltimos segmentossiguen el mismo procedimiento hasta finalizar, con exito, la transmisin.

Observese que el segmento nmero 23 vuelve a tener activado el flag de FIN como en el segmento nmero 19.Esto es lgico ya que falcon indic que el segmento 19 no haba sido recibido y por lo tanto desconoca el hecho deque darkstar estaba intentando cerrar la conexin. Por esta razn, darkstar vuelve a indicar el cierre de la conexin.

1.8. Prcticas

1.8.1. Transicin de Estados

Ejercicio1 En este ejercicio se pretende visualizar los diferentes estados del cliente TCP a lo largo de una conexin.Para ello se va a utilizar el programa sock de R. Stevens en modo cliente, para generar trfico. El programa sockpermite generar trfico TCP y UDP actuando como cliente. Actuando como servidor, sock se convierte en un sumiderodel trafico generado por el cliente. sock tiene varias opciones para configurar el funcionamiento, los tamaos de losbuffers, el nmero de buffers a transmitir, etc (para ver todas las opciones ejecutar sock sin parmetros).

La mquina socksrv con direccin IP 172.16.5.10 tiene ejecutndose en el puerto 7777 un servidor tcp sock. Entrela mquina uml1 y el puerto 7777 de socksrv se ha aadido un retardo medio de 1.2 segundos (ida y vuelta).

uml1socksrv

eth1172.16.5.10/24

router

eth1192.168.1.100/24

eth2192.168.1.1/24

eth1172.16.5.1/24

Net1 Net0tap1 tap0

socksrv :sock tcp 7777sock udp 7777

Packet mangling-Delay pkts-Loss pkts

En primer lugar pondremos en marcha la simulacin utilizando el comando:

h o s t $ s i m c t l t c p s t a r t

En este ejercicio, se ha habilitado el acceso a travs de una consola de comandos a la mquina socksrv. La mquinauml1 tiene habilitadas dos consolas de comandos, la 0 y la 1. El ejercicio se realiza desde las consolas de comandosde uml1 y de socksrv Para ello abriremos ambas consolas uml1 de ejecutando el comando:

h o s t $ s i m c t l t c p g e t uml1 0 ; s i m c t l t c p g e t uml1 1

21

De la misma manera, ejecute el comando necesario para abrir la consola de socksrv.Trabajando en uml1, desde una de las consolas visualizaremos el estado de la conexin TCP cliente de forma

continua mediante el comando netstat. Para ello construimos el siguiente comando, que nos permitir visualizar losestados del cliente TCP y salvar los resultados en el fichero de texto client.txt.

h o s t $ whi le s l e e p 1 ; do n e t s t a t t n | g r ep 7777 | t e e a c l i e n t . t x t ; done

De forma equivalente, en socksrv ejecutaremos el comando anlogo para observar la transicin de estados en elservidor TCP y guardaremos los resultados el fichero server.txt

La generacin de trfico TCP se realizar desde la otra consola de uml1, ejecutando el programa sock para queenve 10 buffers de longitud 1024 bytes (longitud por defecto), hacia el puerto 7777 tcp de socksrv.

h o s t $ sock n50 i 1 7 2 . 1 6 . 5 . 1 0 7777

En las consolas donde se ejecuta el netstat (en el cliente y en el servidor) veremos los diferentes estados de lasmquinas TCP, los cuales iran evolucianando a medida que se establezca la conexin, se transmitan los buffers yfinalmente, se cierre la conexin.

Ntese que mediante el comando netstat podemos observar el estado del TCP en un cierto instante de tiempo.Si utilizamos el wireshark para capturar las tramas durante la transmisin, podremos ver los paquetes, que son loseventos responsables del cambio de estado de los TCPs. Responda a las siguiente preguntas:

1. Ayudndose del la Figura 1.9, interprete cada uno de los estados que ha visualizado, indicando, adems, cmose ha llegado a cada uno de esos estados.

2. El servidor sock se ha ejecutado con las opciones:sock -i -F -Q 5 -s 7777.Qu efecto tiene la opcin -Q 5 sobre la transicin de estados en el cliente?Cmo afectara en la transicin de estados de cliente si no se hubiese utilizado esa opcin en el servidor?

Ejercicio2 En este ejercicio se comprobar que en estado TIME_WAIT, no es posible utilizar el mismo puerto paravolvernos a conectar al servidor. Para ello ejecutamos:

h o s t $ sockn8 i v 1 7 2 . 1 6 . 5 . 1 0 7777

Con la opcin -v (verbose), se obtendr a travs del terminal, el puerto que est utilizando el cliente para conectarse alservidor. Una vez acabada la conexin pero todava en estado TIME_WAIT, volvemos a ejecutar el cliente utilizandocomo puerto de salida (#port) el valor de puerto obtenido en la conexin anterior, mediante el comando

h o s t $ sockn8 i b # p o r t 1 7 2 . 1 6 . 5 . 1 0 7777

La opcin -b #port obliga al cliente a utilizar el puerto #port para la conexin. (Ntese que #port tiene que ser un valornumrico)

Finalmente, estime la duracin del estado TIME_WAIT.

Ejercicio3 El objetivo de este ejercicio es la captura y anlisis de trfico UDP, con objeto de comparar este estudiocon la captura y anlisis de trfico TCP que se realizar en ejercicios posteriores.

El servidor que se utilizar para conectarnos y enviar trfico UDP est en el puerto 7777 del host 172.16.5.10.Como en los ejercicios anteriores, se utilizar el programa sock incluyendo la opcin -u para indicar que deseamostrfico UDP. Para poder observar el trfico que vamos a generar utilizaremos wireshark.

Una vez capturado el trfico, analice los datagramas y responda a las siguientes preguntas:1. Cuntos segmentos se utilizan para la apertura de la conexin?2. Cual es el puerto UDP del cliente?

22

3. Pueden coexistir simultneamente dos clientes UDP en la misma mquina, con el mismo puerto de salida?Disee un comando para comprobar su hiptesis.

4. Pueden coexistir simultneamente un cliente UDP y otro TCP en la misma mquina, con el mismo puerto desalida? Disee comandos para comprobar su hiptesis.

5. Es posible tener un servidor TCP y otro UDP en la misma mquina y con el mismo puerto? Disee comandospara comprobar su hiptesis.

1.8.2. Anlisis de trfico

Ejercicio4 En este primer ejercicio de captura de trfico TCP, se realizar un telnet al puerto de echo del servidor172.16.5.10; (el puerto de echo de un servidor, devuelve los mismos datos que se han enviado). Realice la captura deuna sesin y analice el trfico de manera semejante al anlisis realizado en la seccin 1.7.1.

Ejercicio5 En este segundo ejercicio de captura de trfico TCP, la conexin debe realizarse al puerto daytime delservidor 172.16.5.10. (Como indica el nombre, el puerto daytime de un servidor proporciona la fecha y hora actual delsistema de ese servidor). Realice la captura de una sesin y analice el trfico de manera semejante al anlisis realizadoen la seccin 1.7.1.

23

05-tcp-book and practs (spanish)

Documents

conexin tcp

conexin descolgandoel

servicio orientado

establecimiento previo

orientado aconexin

transmission control

internet protocol

extremo receptor