Redes de Computadores Tema 4: TCP/IP Parte III.

Presentación del tema: "Redes de Computadores Tema 4: TCP/IP Parte III."— Transcripción de la presentación:

1 Redes de Computadores Tema 4: TCP/IP Parte III

2 Contenido PARTE I: PARTE II: PARTE III: Introducción
Arquitectura TCP/IP Interfaz de red Direccionamiento IP PARTE II: Nivel IP Encaminamiento PARTE III: Nivel de transporte Nivel de aplicación

3 El nivel de transporte Transmission Control Protocol Introducción
El protocolo de la capa de transporte, ofrece la comunicación lógica entre procesos de aplicación que se ejecutan en diferentes hosts. Desde la perspectiva de una aplicación esta comunicación lógica, es percibida como si los hosts que ejecutan los procesos estuvieran conectados directamente. Aplicación (HTTP, SMTP, SSL ,etc.) Acceso a los servicios Internet de las aplicaciones Transporte (TCP/UDP) Transferencia fiable. Segmentación. Control del flujo y errores. Identificación por puertos Internet (IPv4/v6) Trans. Paquetes entre sistemas finales. Direccionamiento IP. Enrutamiento Interfaz de red (o capa de acceso a la red) NIC DRIVER (Enlace) + NIC Físico (Ethernet, FDDI, X.25, FR, ATM, etc.)

4 TCP vs. UDP TCP UDP Protocolo orientado a conexiones
Mas lento pero confiable Control de flujo Reconocimiento/ retransmisiones Desde pequeñas a grandes cantidades de datos UDP Protocolo sin conexiones. Mas rápido pero sin garantía (best effort) Sin control de flujo Sin reconocimiento Pequeñas cantidades de datos

5 Vista de TCP se los servicios de red TSAP (Puertos)
En sentido estricto una conexión entre dos entidades usuarias del nivel de transporte queda identificada por los TSAPs en los que conectan cada una (podemos pensar en el TSAP como el conector telefónico, diríamos entonces que una conversación telefónica queda perfectamente especificada por los números de teléfono de las dos rosetas donde están enchufados los aparatos con los que se está hablando). Dado que la conexión en el nivel de transporte siempre se suele realizar con el protocolo TCP este dato es innecesario y se suele omitir. Sin embargo en un mismo host un número de port puede ser utilizado simultáneamente por una aplicación para UDP y por otra para TCP; esto no plantea ningún conflicto ya que son TSAPs diferentes. Así pues, una conexión de dos entidades usuarias del nivel de transporte se especifica por la combinación: Dirección IP host x + port host x + dirección IP host y + port host y Para comprender la relación entre los puertos y las conexiones en TCP veamos un ejemplo concreto: supongamos que 1 usuario desde un host de dirección IP inician una sesión de logon remoto (Telnet) hacia el host de dirección ; cada uno de ellos ejecutará en su host un programa telnet cliente que abrirá una conexión con el servidor Telnet (puerto 23) en el otro; las conexiones establecidas podrían ser por ejemplo: Usuario: con servidor El nivel de transporte ofrece sus servicios al nivel de aplicación a través de unos SAPs específicos, que en el caso de Internet son los denominados ports o puertos. Estos puertos se denominan también TSAPs (Transport Service Acces Point). Sistema X Sistema Y ApX ApX TSAP TSAP Transporte Transporte Protocolo de transporte Servicios de red: Control de la Conexión, el Encaminamiento, la Congestión y el Direccionamiento NSAP: Network Service Access Point

6 Puntos de acceso al servicio de transporte TSAP (Puertos)
Cada puerto del Nivel de Transporte proporciona a las aplicaciones un interfaz de acceso a la red de comunicaciones, capaz de dialogar con otra aplicación situada en un puerto en una máquina remota. El puerto es un número entero entre 0 y Por convenio los números 0 a 1023 están reservados para el uso de servicios estándar, por lo que se les denomina puertos bien conocidos o well-known ports. Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma temporal, pero también pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de usuario. Los puertos dinámicos/privados no tienen significado fuera de la conexión TCP en la que fueron usados (rango de puertos dinámicos/privados: al Puertos UDP Puertos TCP 0 Reservado 7 ECHO 13 DAYTIME 37 TIME 42 NAMESERVER 53 DOMAIN 69 TFTP 20 FTP-DATA 21 FTP (control) 23 TELNET 25 SMTP 80 HTTP 995 POP3 sobre SSL NSAP: Network Service Access Point

7 Puntos de acceso al servicio de transporte y de red TSAP y NSAP
El Socket designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada. Apy Transporte Protocolo de transporte Sistema X Sistema Y ApX Internet Interfaz de red NSAP TSAP NSAP: Network Service Access Point

8 El protocolo UDP [1] William Stallings: Comunicaciones y Redes de Computadores. Prentice Hall El protocolo de datagrama de usuario (UDP, User Datagram Protocol), especificado en el RFC 768, proporciona un servicio no orientado a conexión para los procedimientos de la capa de aplicación. Luego: UDP no necesita preestablecer la comunicación antes de enviar los datos, Una aplicación puede generar y enviar datos en cualquier momento. UDP permite que una aplicación se retrase un tiempo arbitrariamente largo entre la transmisión de dos mensajes. UDP no mantiene estado, y no utiliza los mensajes de control La comunicación se compone sólo de los mensajes de datos. No hay mensajes de control para detener una aplicación UDP UDP Protocolo de transporte (UDP) TH Datos AH Internet Internet Protocolo red (IP) RH TH AH Datos

9 Formato del datagrama UDP
Número de puertos=216 (65.536) TSAPs La cabecera UDP consta de 4 campos de los cuales 2 son opcionales (con fondo azul y verde). Los campos de los puertos fuente y destino son campos de 16 bits que identifican el proceso de origen y recepción. Ya que UDP carece de un servidor de estado y el origen UDP no solicita respuestas, el puerto origen es opcional. En caso de no ser utilizado, el puerto origen debe ser puesto a cero. A los campos del puerto destino le sigue un campo obligatorio que indica el tamaño en bytes del datagrama UDP incluidos los datos. El valor mínimo es de 8 bytes. El campo de la cabecera restante es una suma de comprobación de 16 bits que abarca una pseudo-cabecera IP (con las IP origen y destino, el protocolo y la longitud del paquete UDP), la cabecera UDP, los datos y 0's hasta completar un múltiplo de 16. El checksum también es opcional en IPv4, aunque generalmente se utiliza en la práctica (en IPv6 su uso es obligatorio). La longitud mínima es de 8 bytes porque esa es la longitud de la cabecera. El tamaño del campo establece un límite teórico de bytes (8 bytes de cabecera bytes de datos) para un datagrama UDP. El límite práctico para la longitud de los datos que se impone por la subyacente IPv4 protocolo es 65,507 bytes ( bytes cabecera UDP - 20 bytes cabecera IP ). En IPv6, los Jumbogramas pueden provocar paquetes UDP de tamaño mayor que bytes. Identifica al proceso origen (opcional) 7 15 23 31 Identifica al proceso destino Puerto origen Puerto destino Longitud mensaje Suma verificación Longitud del datagrama, incluida cabecera (mínimo 8B, por la cabecera) Datos del proceso de aplicación (pe. DNS, SNMP, NFS, RIP, Telefonía, streaming video) (carga útil o payload) El mismo algoritmo usado en IP y TCP (opcional). Si no se incluye su valor es cero De 0 a bytes de datos

10 El protocolo de transporte TCP
[1] William Stallings: Comunicaciones y Redes de Computadores. Prentice Hall [5] D.Comer. Computer Networks and Internets El protocolo TCP (Transmission Control Protocol), TCP se caracteriza por proporcionar una comunicación fiable entre pares de procesos (usuarios TCP) a través de una gran variedad de redes e interconexiones fiables y no fiables. TCP ofrece las siguientes propiedades: Servicio orientado a la conexión Comunicación P2P Comunicación Full Dúplex TCP permite que dos aplicaciones inicien de manera fiable la comunicación Antes de cerrar una conexión, TCP asegura que todos los datos han sido entregados y que ambas partes han acordado de cerrar la conexión TCP TCP Protocolo de transporte (TCP) TH Datos AH Internet Internet Protocolo red (IP) RH TH AH Datos

11 Formato del segmento TCP
El número de secuencia y el número de confirmación hacen referencia a octetos en lugar de a segmentos completos. Por ejemplo, si un segmento contiene el número de secuencia 1001 e incluye 600 octetos de datos, el número de secuencia se refiere al primer octeto del campo de datos. El segmento siguiente en orden lógico tendrá el número de secuencia De esta manera, TCP está lógicamente orientado a flujo: acepta un flujo de octetos del usuario, los agrupa en segmentos según vea apropiado y numera cada octeto del flujo. Ventana. Tamaño de ventana o ventana de recepción (16 bits): Tamaño de la ventana de recepción que especifica el número máximo de bytes que pueden ser metidos en el buffer de recepción o dicho de otro modo, el número máximo de bytes pendientes de asentimiento. Es un sistema de control de flujo. Puntero de datos urgentes: indica el final de éstos, ya que el segmento podría contener datos no urgentes. TCP no marca el principio de los datos urgentes, es responsabilidad de la aplicación averiguarlo. Opciones (Variable): un ejemplo lo constituye la opción que especifica la longitud máxima de segmento que será aceptada Tamaño de los datos TCP divide (o agrupa) los mensajes recibidos del nivel de aplicación en TPDUs denominadas segmentos; en el momento de establecer la conexión cada host informa al otro del máximo tamaño de segmento que está dispuesto a aceptar; este como mínimo de 536 bytes, , correspondiente normalmente a un datagrama IP de 576 bytes (por defecto, el tamaño de datagrama IP es de 576 bytes, RFC 791) menos 20 bytes de cabecera IP y 20 de cabecera TCP (la longitud de segmento se refiere a la parte de datos de TCP). Identifica al proceso origen (opcional) Puerto origen Número de secuencia 15 31 7 23 Puerto destino Número de confirmación Ventana 4 Reserv Banderas (9bits) Suma comprobación Puntero urgente Opciones (variable) Relleno Datos del proceso de aplicación (carga útil o payload) Tamaño mínimo = 536 bytes, Long. Cab Identifica al proceso destino Primer octeto del campo de datos que el receptor del segmento espera recibir. Este acusa recibo de todos los bytes anteriores (si los hay). El número de secuencia se refiere al primer octeto del campo de datos Tamaño de la cabecera en palabras de 32 bits. Lo normal es 5 número máximo de bytes que pueden estar pendientes de asentimiento Para poder añadir características no cubiertas por la cabecera fija. Se utiliza para asegurarse que la cabecera acaba con un tamaño múltiplo de 32 bits. ¡Un segmento TCP siempre se transporta en un datagrama IP!

12 Formato del segmento TCP Banderas (flags)
Banderas o Flags (9 bits): NS (1 bit): ECN-nonce concealment protection. Para proteger frente a paquetes accidentales o maliciosos que se aprovechan del control de congestión para ganar ancho de banda de la red. CWR (1bit): Congestion Window Reduced. El flag se activa por el host emisor para indicar que ha recibido un segmento TCP con el flag ECE activado y ha respondido con el mecanismo de control de congestión. ECE (1 bit): Para dar indicaciones sobre congestión. URG (1 bit): Indica que el campo del puntero urgente es válido. ACK (1 bit): Indica que el campo de asentimiento es válido. Todos lo paquetes enviados después del paquete SYN inicial deben tener activo este flag. PSH (1 bit): Push. El receptor debe pasar los datos a la aplicación tan pronto como sea posible. RST (1 bit): Reset. Reinicia la conexión. SYN (1 bit): Synchronice. Sincroniza los números de secuencia para iniciar la conexión. FIN (1 bit): El emisor finaliza el envío de datos Identifica al proceso origen (opcional) 4 7 15 23 31 Identifica al proceso destino Puerto origen Puerto destino Primer octeto del campo de datos que el receptor del segmento espera recibir. Este acusa recibo de todos los bytes anteriores (si los hay). El número de secuencia se refiere al primer octeto del campo de datos Número de secuencia Número de confirmación Tamaño de la cabecera en palabras de 32 bits. Lo normal es 5 Long. Cab Reserv Banderas (9bits) Ventana número máximo de bytes que pueden estar pendientes de asentimiento URG ACK PSH RST SYN FIN

13 Establecimiento de una conexión TCP Conexión en 3 fases
La conexión siempre se realiza a iniciativa del cliente, y siempre se lleva a cabo mediante el intercambio de tres mensajes 1. En primer lugar, el host que desea iniciar la conexión ejecuta una primitiva CONNECT especificando la dirección IP y el puerto con el que se desea conectar, el tamaño máximo del segmento que está dispuesto a aceptar y opcionalmente otros datos, como alguna contraseña de usuario. Entonces la primitiva CONNET hace una apertura activa, enviando al otro host un paquete que tiene el bit SYN activado, indicándole también el número de secuencia inicial "x" que usará para enviar sus mensajes. El número de secuencia (seq) no empieza normalmente en 0, sino en un valor denominado ISN (Initial Sequence Number) elegido al azar; el ISN sirve de ‘PIN’ en el saludo a tres vías para asegurar la autenticidad de la comunicación. Supongamos que ISN=100 Nota: los segmentos SYN y FIN se consideran de datos (1 byte), de aquí que seq se incremente. Esto es así porque el estándar sugiere utilizar un contador (ISN) entero incrementado en 1 cada 4 μs aproximadamente. En este caso el contador se da la vuelta (y el ISN reaparece) al cabo de 4 horas 46 min. Se usa para sincronizar los números de secuencia en tres tipos de segmentos: petición de conexión, confirmación de conexión (con ACK activo) y la recepción de la confirmación (con ACK activo). CTL = Control bits in TCP header (URG, ACK, PSH, RST, SYN, FIN)=SYN Normalmente el segmento SYN no lleva datos, pero podría llevarlos. 2. El host receptor recibe el segmento registra el número de secuencia “100" y, si desea abrir la conexión, responde con un acuse de recibo “ " con el bit SYN activado e incluye su propio número de secuencia inicial “300", dejando entonces abierta la conexión por su extremo. El número de acuse de recibo “ " significa que el host ha recibido todos los octetos y espera “ " a continuación. Si no desea establecer la conexión, envía un contestación con el bit RST activado, para que el host en el otro extremo lo sepa. 3. El cliente envía un tercer mensaje (Número de secuencia seq=100+1) en el que acusa recibo del segundo (ack=300+1) y considera establecida la conexión. Cuando recibe este tercer mensaje el servidor considera establecida la conexión cliente servidor LISTEN A B LISTEN SYNSENT ISN=100 seq:100 SYN:1 SYNRCVD ISN=300 seq:300 SYN&ACK:1 ack:101 ESTAB seq:101 ACK:1 ack:301 ESTAB ISN (Initial Sequence Number)

14 Fin de la conexión TCP Desconexión simétrica en 4 pasos
Una conexión puede terminarse de forma simétrica o asimétrica. La terminación asimétrica es unilateral, es decir uno de los dos hosts decide terminar y termina la conexión en ambos sentidos. En la terminación simétrica cada host corta la conexión únicamente en el sentido en el que emite datos; podemos considerar la terminación simétrica como dos circuitos simplex donde cada uno es controlado por el emisor. La terminación asimétrica se considera anormal y puede provocar la pérdida de información, ya que cuando un host ha enviado la TPDU de desconexión ya no acepta más datos; entretanto el otro host podría haber enviado una TPDU de datos que no será aceptada. El host que toma la iniciativa puede ser el cliente o el servidor. FIN-WAIT-1 El cliente, después de haber enviado un FIN , está esperando LA CONFIRMACIÓN . En este estado, el cliente todavía puede recibir datos desde el servidor, pero ya no aceptará los datos de su aplicación local que se envían al servidor. CLOSE El servidor recibe del cliente FIN . Se envía un ACK para reconocer el FIN . El servidor debe esperar a que la aplicación de usarlo se cierre, por lo que la aplicación aquí puede demorarse para terminar lo que está haciendo. FIN-WAIT-2 La confirmación ha llegado y el cliente está esperando el FIN del servidor. En este punto el servidor aún puede mandar datos. El cliente está esperando por el FIN del servidor. LAST ACK El servidor envía su FIN al cliente. El número de secuencia no cambia porque no ha habido reconocimiento TIME-WAIT El cliente espera un período de tiempo igual al doble del tiempo máximo de vida del segmento (Máximum segment life, MSL), después de enviar el ACK. El MSL es el tiempo máximo de vida de un segmento. Dado que un segmento TCP viaja encapsulado en un datagrama IP, y éste tiene un campo TTL (time-to-live), un segmento TCP también tendrá un tiempo de vida en la red. ¿Por qué el TCP que realiza un cierre (cliente o servidor) activo debe esperar un cierto tiempo?. El cierre de una conexión nunca es una cosa sencilla, ya que los paquetes de cierre pueden perderse y los extremos TCP pueden quedarse en un estado incorrecto. Refiriéndonos a la Figura, una vez que el cliente ha recibido el segmento FIN, pasa al estado TIME_WAIT y envía un segmento de reconocimiento. Puede suceder que ese segmento de reconocimiento se “pierda” y no llegue nunca a su destino. Si así fuera el caso, el servidor volvería a retransmitir el segmento FIN. Por tanto, el cliente espera un tiempo prudencial (2· MSL) de manera que pueda recibir esa retransmisión del segmento FIN si el reconocimiento se ha perdido. RFC 793 especifica MSL como 2 minutos y los sistemas de Windows por defecto a este valor, pero se puede ajustar mediante el TcpTimedWaitDelay configuración del registro. Una vez efectuada la desconexión el host que inició el proceso está un cierto tiempo a la espera por si aparecen segmentos retrasados cliente servidor ESTAB A B ESTAB FIN-WAIT1 seq:100 FIN:1 CLOSE WAIT seq:300 ACK:1 ack:101 FIN-WAIT2 LAST ACK seq:300 FIN,ACK:1 ack:101 TIME WAIT 2MSL seq:101 ACK:1 ack:301 CLOSED CLOSED Espera TIMEWAIT Espera FIN Espera ACK Cierre de la app Máximum segment life, MSL

15 La congestión y el control de flujo
[1] William Stallings: Comunicaciones y Redes de Computadores. Prentice Hall La congestión, tiene dos efectos negativos principales: cuando la congestión empieza a producirse, el tiempo de transmisión a través de la red o interconexión de redes aumenta. conforme la congestión se hace más severa, la red o los nodos de la interconexión descartan paquetes. El mecanismo para detectarla es implícito, por la pérdida de segmentos. El mecanismo de control de flujo tiene como fin primario permitir que el destinatario restrinja el flujo de segmentos de una fuente y evitar así la saturación de su memoria temporal del destino. Este mismo mecanismo de control de flujo se utiliza para proporcionar control de congestión sobre Internet entre la fuente y el destino. Se puede utilizar para identificar el comienzo de la congestión (identificando el incremento de los tiempos de retardo y de los segmentos descartados) y reaccionar mediante la reducción del flujo de datos. Si muchas de las entidades TCP que operan a lo largo de una red practican este tipo de control, la congestión de la red se puede aliviar.

16 Control del flujo mediante ventana
En TCP el tamaño de ventana indica el número de octetos que pueden ser recibidos y el receptor indica al emisor, en cada trama enviada, qué tamaño de ventana tiene disponible para recibir el siguiente segmento, realizando, de esta manera, el control de flujo. Si se indica un tamaño de ventana 0, el emisor deja de enviar segmentos hasta que recibe otro paquete indicando un tamaño de ventana distinto de 0. Cuando A manda 1000B Seq pasa de 1000 a O sea no los contabiliza hasta que no recibe ACK. Una vez recibida pasa a 2001, reconociendo el envío. Véase que el reconocimiento anterior van otros 1000B de B. Cuando A procede a enviar otros 1000B a la vez confirma los 1000B anteriores de B y Seq pasa de 1001 y ACK de 1501 a 2501 NOTA: Observe que A después de mandar el 4º segmento, ack (en el segmento enviado por B) pasa de 2501 a 5001 porque confirma los 4k recibidos previamente, pero a la vez detiene la emisión de A con un valor de ventana w=0. B MSS=1000; Seq:1500; win:4000 MSS=1000; Seq:1000; win:4000 A 4k 4k Buffer de A DATOS Buffer de B seq:1001 1k ack:1501 W:4000 4k 1k W:3000 seq:1501 1k ack:2001 W:3000 4k 1k W:3000 seq:2001 1k ack:2501 W:3000 4k 2k seq:3001 1k ack:2501 W:3000 W:2000 seq:4001 1k ack:2501 W:3000 4k 3k W:1000 4k W:0 ¡Buffer lleno! seq:2501 ack:5001 W:0 Bloqueo La aplicación lee 2k 4k 2k seq:2501 ack:5001 W:2000 W:2000

17 Recuperación ante la pérdida de segmentos
La pérdida de segmentos puede hacer que un enlace de 100Mbps quede reducido a un throughput de 1Mbps TCP es un protocolo muy vulnerable a la pérdida de segmentos que puede deberse a diversas causas: errores en la comunicación, pérdida o retraso del ACK, buffers saturados, error de checksum, etc. Algo que influye gravemente en la eficiencia de la red Para evitarlo se puede hacer lo siguiente: Si después de enviar un segmento no se recibe el ACK dentro de un cierto tiempo se retransmite el segmento Problema: si un segmento experimenta una excesiva demora, el remitente puede retransmitir el segmento a pesar de que ni el segmento ni su ACK se han perdido. Esto puede producir copias de segmentos. Enviar todos los segmentos a partir de ese (retroceso n) Repetición selectiva

18 Pérdida de segmentos Retransmisión automática, sin ventana
Petición de repetición automática (ARQ) Los errores (tramas dañadas y tramas perdidas) , una vez detectados, se recuperan con retransmisiones. La solicitud de repetición automática (ARQ) es un método de control de errores para la transmisión de datos que hace uso de códigos de detección de errores, acuse de recibo y / o mensajes de acuse de recibo negativo, y los tiempos de espera para lograr la transmisión de datos fiable. Un acuse de recibo es un mensaje enviado por el receptor para indicar que trama de datos . Pueden ocurrir dos tipos de error. El primero consiste en que la trama que llega al destino puede estar dañada. El receptor detecta este hecho mediante la utilización de técnicas de detección de errores (Checksum) y, simplemente, descartará la trama. Para dar respuesta a esta situación, la estación fuente utiliza un temporizador. De este modo que, tras el envío de una trama, la estación espera la recepción de una confirmación; si no se recibe ninguna confirmación antes de que el temporizador expire, se procederá a reenviar la misma trama. Obsérvese que este método exige que el emisor conserve una copia de la trama transmitida hasta que se reciba la confirmación correspondiente. [William Stallings: Comunicaciones y Redes de Computadores] Con el fin de poder detectar cualquier modificación de los datos durante su transmisión, TCP calcula un Checksum que incluye en la cabecera y que verifica la integridad del segmento. Si un segmento llega con un Checksum no válido, TCP lo descarta, no enviando un reconocimiento de su recepcepción. Puesto que los segmentos TCP se transmiten en forma de datagramas IP, y dado que los datagramas IP pueden llegar desordenados, los segmentos TCP pueden recibirse desordenados. El protocolo TCP receptor reordena los datos, si es necesario, entregándolos a la aplicación en el orden correcto. Emisor Receptor seq:1001 1k ack:1501 Tiempo de espera de la confirmación seq:1501 ack:2001 seq:2001 1k ack:1501 Datos perdidos Tiempo de espera de la confirmación Timeout Datos corruptos seq:2001 1k ack:1501 Las tramas con errores son descartadas. Es como si se hubiera perdido. =>no hay reconocimiento Timeout seq:2001 1k ack:1501 seq:1501 ack:3001

19 Pérdida de segmentos Retroceso n (Go back n)
En esta técnica, una estación puede enviar una serie de segmentos secuencialmente (hasta) algún valor máximo dado (ventana). Al utilizar la técnica de control de flujo mediante ventana deslizante, el número de segmentos pendientes de confirmar se determina mediante el tamaño de la ventana. Mientras no se produzcan errores, el destino confirmará las tramas recibidas como es habitual . Si la estación destino detecta un error en un segmento, la estación destino descartará ese paquete y todos las que se reciban con posterioridad hasta que dicho segmento llegue correctamente. El emisor A entra en bloqueo porque sabe que la ventana de receptor era 3000, y ya ha enviado 3 segmentos de 1000. Emisor (A); seq: 1000; win:4000 Receptor (B); seq:1500; win:4000 Bloqueo ESTAB seq:1001 1k ack:1501 W:4000 seq:1501 ack:2001 W:3000 seq:2001 1k ack:1501 W:4000 seq:3001 1k ack:1501 W:4000 seq:4001 1k ack:1501 W:4000 Datos perdidos Segmento descartado seq:1501 ack:3001 W:2000 seq:3001 1k ack:1501 W:4000 seq:4001 1k ack:1501 W:4000 Time outs seq:1501 ack:5001 W:0

20 Intercambios de datos especiales El flag PUSH
TCP elige la distribución de los datos en segmentos. Por razones de eficiencia suele acumular un número razonable de octetos antes de un envío. Esto a veces penaliza el rendimiento de una aplicación. Ejemplo: Terminal remota (TELNET). La activación del flag PSH, permite a la aplicación obligar a la entidad TCP emisora a crear inmediatamente un segmento y a enviarlo. Por su parte, la entidad TCP receptora los pondrá a disposición de la aplicación de inmediato. Para ello, los datos se envían sin esperar a llenar un segmento. Puerto origen Número de secuencia 15 31 7 23 Puerto destino Número de confirmación Ventana 4 Reserv Banderas (9bits) Long. Cab URG ACK PSH RST SYN FIN

21 Intercambios de datos especiales Los datos urgentes. El flag URG
Como los datos urgentes viajan entre los datos de un segmento, TCP tiene un mecanismo para encontrarlos: un puntero. TCP no marca el principio de los datos urgentes. Cuando URG=1, el puntero tiene la posición de del ultimo byte de los datos urgentes. Los datos urgentes son aquellos que indicar situaciones de excepción Ejemplo: Abortar programas en una terminal remota Los datos urgentes, no están sujetos al control de flujo. Después de haber leído todos los datos urgentes, la aplicación vuelve al modo normal de funcionamiento 4 7 15 23 31 Puerto origen Puerto destino Número de secuencia Número de confirmación Long. Cab Reserv Banderas (9bits) Ventana Suma comprobación Puntero urgente URG ACK PSH RST SYN FIN Cuando URG=1, el puntero tiene la posición de del ultimo byte de los datos urgentes

22 Escenarios TCP (I): flujo normal Parte (1/2)
A) Segmentos 1,2 y 3. Conexión en tres fases 1.La inicia el cliente envía un segmento SYN con su ISN (Initial Sequence Number)= MSS=1024 2.El servidor responde SYN+ACK y su propio ISN (Initial Sequence Number): ack MSS=1024 3.El cliente recibe SYN+ACK y responde con ACK. La confirmación (ack) se escribe ahora con un offset=1 (ISN+1), con el fin de aliviar la notación. No se indica seq ya que este no cambia porque el segmento no lleva datos. Notas: los segmentos SYN se consideran de datos (1 byte), de aquí que seq se incremente. Números de secuencia: se escribe el primero y el último (este es el que viaja en el segmento). Cuando no se explicita, se asume que es el indicado por ACK B) Segmentos 4,5 y 6. Envío de datos (3x1024 B) con el flag PSH activado Se trata de un envío inmediato. Los números de secuencia de los 3 segmentos son: , =2049, =3073 C) Segmentos 7 y 8. Confirmación de los datos En primer lugar estos segmentos no llevan nº de secuencia porque no ha cambiado, ya que no llevan datos. Cuando TCP recibe datos si no tiene datos que enviar de vuelta no envía el ACK inmediatamente. En vez de eso espera un poco a ver si la aplicación genera datos y de ese modo aprovecha para enviar el ACK con datos (decimos que el ACK va ‘piggybacked’). El tiempo que TCP espera para ver si el ACK puede ir ‘piggybacked’ con datos se conoce como ‘timer de ACK retrasado’. En muchos sistemas ese timer suele ser de unos 200 ms. Si se agota el timer sin que la aplicación haya producido datos se envía un segmento. En nuestro caso, suponiendo que se trata de una aplicación Telnet, como el servidor telnet no escribe en el buffer de TCP el carácter a transmitir antes de los 200 ms se tiene que enviar un ACK vacío (7 y 8). Finalmente, nótese que en el segmento 7, la ventana se mantiene porque se supone que los 2048 B recibidos (segmentos 4 y 5) y confirmados se entregan inmediatamente a la aplicación, ya que el flag PSH estaba activado. Además, hay que subrayar el hecho de que se evita confirmar todos los datos recibidos en un solo ack sin datos, para evitar una nueva emisión y así controlar el flujo reduciendo el tráfico. A esta estrategia también contribuye la reducción de ventana. ISN+1025 ISN+1 ISN Syn 1k

23 Escenarios TCP (I): flujo normal Parte (2/2)
C) Segmentos Segmentos de datos del cliente Los segmentos 11, 12 y 13 llegan y se colocan en la cola de entrada de IP. Cuando segmento 11 es procesado por la entidad TCP, se le asigna un timer de retraso del ACK, para ver si es posible mandarlo con datos. Cuando el segmento 12 se procesa, se genera un ACK (segmento 14) para los segmentos 11 y 12. El segmento 13 provoca que la conexión programe de nuevo por un ACK con retraso, pero antes de el tiempo expire, el segmento 15 se procesa, haciendo que el ACK (segmento 16) sea enviado inmediatamente. Es importante notar que el ACK en los segmentos 7, 14, y 16 reconocen dos segmentos recibidos. Con el protocolo de ventana deslizante de TCP receptor no tiene la obligación reconocer cada paquete recibido. En suma, con TCP, los ACKs son acumulativos, puede reconocer que el receptor ha recibido correctamente todos los bytes a través del número de secuencia reconocido menos uno. En este ejemplo tres de los ACKs reconocen bytes de datos y dos reconocen bytes de datos. (ignorando los ACK del establecimiento de la conexión y terminación.) D) Segmentos 17, 18, 19 y 20. Desconexión en 4 fases

24 Escenarios TCP (II) Emisor rápido/receptor lento Parte (1/2)
La figura muestra otro escenario, esta vez un emisor rápido y un receptor lento. La dinámica es diferente de nuevo. A) Segmentos 1,2 y 3. Proceso de conexión en 3 fases (o tres vías) ISM del cliente: MSS: En cambio, el servidor tiene un MSS=1024, lo que permite augurar que es mas lento que el cliente. B) Segmentos 4,5 6 y 7. Transmisión de datos al servidor. El emisor transmite cuatro segmentos (4-7) hasta agotar la ventana del receptor. Debe apreciarse como el cliente detiene su emisión de datos antes de tener una indicación del servidor acerca de su ventana, a la espera de un reconocimiento (ACK). C) Segmentos 8 y 9. Reconocimientos El receptor envía el ACK (segmento 8), pero la ventana anunciada es 0. Esto significa que el receptor tiene todos los datos, pero aún están todos en el buffer TCP del receptor, ya que la aplicación no ha tenido la oportunidad de leer los datos, pesar de que el flag PSH está activado. En realidad, este ACK sirve para controlar el flujo excesivo del cliente. Un segundo ACK (llamado actualización de la ventana) se envía 17.4 ms tarde, anunciando que el receptor puede ahora recibir otros bytes. Aunque esto parece un ACK, se llama una actualización de la ventana, ya que no reconoce ningún dato nuevo, simplemente amplia la ventana.

25 Escenarios TCP (II) Emisor rápido/receptor lento Parte (2/2)
D) Segmentos 10 al 13. El emisor transmite sus últimos cuatro segmentos (10-13), pero seta vez sin el flag PSH activado, y de nuevo se llena la ventana del receptor. Obsérvese que el segmento 13 contiene dos bits de bandera: PUSH y FIN. F) Segmentos 14 y 15 Nuevamente el receptor envía el ACK que confirma los datos recibidos, pero la ventana anunciada es 0 (contención del flujo). Después un segundo ACK (llamado actualización de la ventana) se envía mas tarde, anunciando que el receptor puede ahora recibir otros bytes. G) Segmentos 16 y 17 Cuando uno de los dos extremos de la conexión desea parar su "mitad" de conexión, basta con transmitir un segmento con el flag FIN activo, que el otro interlocutor asentirá con un ACK. Esto, técnicamente, significa que se suspende el envío de datos en una dirección y que el cliente deberá comunicar a su aplicación este cierre (un caso raro en la practica). La razón de este cierre unilateral es, probablemente, la saturación del servidor. Todo ello sin olvidar que, como es sabido, una desconexión completa típica requiere un par de segmentos FIN y ACK desde cada lado de la conexión.

26 Procesos de aplicación de TCP/IP
6. Nivel de aplicación Procesos de aplicación de TCP/IP

27 Protocolos de aplicación
Muchos protocolos de la capa de aplicación de Internet están plenamente especificados en los RFCs y por lo tanto son del dominio público. Por ejemplo, la especificación HTTP 1.1 está incluida en RFC 2068, hecha pública enero en de 1997. Si se desarrolla un navegador (cliente HTTP) que sigue las reglas de la HTTP 1.1 (RFC 2068), será capaz de recuperar páginas web de cualquier servidor Web que también ha seguido las reglas del HTTP 1.1. Rpc: Remote Procedure Call Domain Name System o DNS (en español «Sistema de Nombres de Dominio») Smtp: Simple Mail Transfer Protocol Nfs: Network File System Un protocolo de la capa de aplicación define cómo los procesos de aplicación (clientes y servidores), que se ejecutan en diferentes sistemas, pasan mensajes entre sí. Aplicación SMTP Telnet SMTP RPC WWW DNS FTP SNMP DNS NFS TCP UDP Internet (IPv4/v6) Trans. Paquetes entre sistemas finales. Direccionamiento IP. Enrutamiento Interfaz de red (o capa de acceso a la red) NIC DRIVER (Enlace) + NIC Físico (Ethernet, FDDI, X.25, FR, ATM, etc.)

28 El modelos de interacción entre sistemas finales
P2P: peer-to-peer Existen dos modelos de interacción entre sistemas finales: Cliente/servidor (C/S) y de igual-a-igual (P2P) Los protocolos C/S y P2P operan en la capa de aplicación y son independientes de los sistemas que los conectan C/S El cliente es diferente del servidor mayor velocidad de acceso La seguridad es mejor P2P Todos los nodos son iguales Menos seguras Aplicaciones en redes domésticas

29 El modelo cliente/servidor
En el modelo cliente/servidor las aplicaciones se dividen en clientes y servidoras, y cada una tiene tares específicas: Clientes: su rol es iniciar las comunicaciones y enviar peticiones a los servidores. Además, interactúa con el usuario. Servidoras: tienen un rol pasivo y responden a las peticiones de los clientes enviando los resultados. Normalmente soportan muchos clientes. P S P P C C C C P P

30 Modelo cliente/servidor
Aplicación TCP Internet (IPv4/v6) Interfaz de red Aplicación TCP Internet (IPv4/v6) Interfaz de red Petición Proceso Cliente Proceso Servidor Respuesta Red

31 Ejemplo de protocolo de aplicación FTP
DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la conexión y de administrar el canal de datos. El DTP del lado del servidor se denomina SERVIDOR DE DTP y el DTP del lado del cliente se denomina USUARIO DE DTP. FTP (siglas en inglés de File Transfer Protocol, 'Protocolo de Transferencia de Archivos') en informática, es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo. El servicio FTP es ofrecido por la capa de aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor y/o apropiarse de los archivos transferidos. Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico. Aplicación TCP Internet (IPv4/v6) Interfaz de red Aplicación TCP Internet (IPv4/v6) Interfaz de red Cliente Interfaz Control Cliente Control Cliente Control Datos Datos Datos 20 21 1021 1027 Red

32 Referencias [1] William Stallings: Comunicaciones y Redes de Computadores. Prentice Hall [2] J Kurose & K Ross: Computer networking (2009) [3] Andrew S. Tanenbaum: Computer Networks (4ª ed 2003). Prentice Hall [4] R.J. Cypser: Communications for cooperating systems . Addison-Wesley [5] D.Comer. Computer Networks and Internets [6] W.R. Stevens. TCP/IP Illustrated