TCP Protcolo de transporte. 4.0.1. Introducción ● En las aplicaciones en red se suele utilizar el modelo cliente servidor. Cliente y servidor funcionan.

Presentación del tema: "TCP Protcolo de transporte. 4.0.1. Introducción ● En las aplicaciones en red se suele utilizar el modelo cliente servidor. Cliente y servidor funcionan."— Transcripción de la presentación:

1 TCP Protcolo de transporte

2 4.0.1. Introducción ● En las aplicaciones en red se suele utilizar el modelo cliente servidor. Cliente y servidor funcionan a nivel de aplicación. ● La capa de transporte recibe los datos de estas aplicaciones y los preparan para su direccionamiento a nivel de red. ● Transferencia extremo a extremo. ● Otras funciones: ● Multiplexación de las comunicaciones. ● Confiabilidad y mantenimiento del orden. ● Manejo de errores.

3 4.1.1.1. Propósito de la capa de transporte. ● Seguimiento de la comunicación individual entre aplicaciones en los hosts origen y destino. ● Mantiene y controla los flujos de comunicación entre aplicaciones. ● Segmentación de datos y gestión de cada porción. ● División del flujo en segmentos y agregación de la cabecera. ● Reensamblaje de segmentos en flujos de datos de aplicación ● Reconstrución del flujo original a partir de los segmentos recibidos. ● Identificación de las diferentes aplicaciones. ● Asociación de un puerto a cada aplicación. ● Separación de las aplicaciones de los detalles de la red. Servir de enlace entre las aplicaciones y la red. ● Adecuarse a las necesidades de las aplicaciones. ● En cuanto a requerimiento de rendimiento y fiabilidad. ● A mayor fiabilidad, menor rendimiento. A mayor rendimiento menor fiabilidad.

4 4.1.1.2. Separación de comunicaciones múltiples ● Supongamos una máquina que se comunica simultáneamente con otras, mediante VoIP y email. ● En el email es aceptable un cierto retardo, pero la información debe ser completa. ● En la conversación VoIP, la información no puede sufrir retardos, pero pequeñas pérdidas de información puede ser aceptable.

5 4.1.1.3. Aspectos sobre el transporte de la información ● Una comunicación que provoca un flujo contínuo de datos puede dificultar: ● La comunicación de otros datos diferentes. ● La recuperación de partes que han sufrido deterioro. ● La división en trozos de los datos de las diferentes comunicaciones permite su multiplexación (entrelazamiento). ● A nivel de TCP se dice que entre las aplicaciones se produce una “conversación”. ● El encabezado agrega información necesaria para el transporte.

6 4.1.2.1. Control de conversaciones ● Segmentación y reensamblaje. ● A nivel de enlace, hay limitaciones en cuanto a la MTU (PDU máxima). ● Transporte contempla este por cuestión de eficiencia, eligiendo un tamaño de PDU adecuado. ● Multiplexación. ● En el encabezado se gestiona información sobre la aplicación responsable de una conversación (puerto). ● Además se puede incluir soporte para: – Conversaciones orientadas a conexión. – Entrega confiable. – Reconstrucción ordenada de datos. – Control del flujo.

7 4.1.2.2. Control de conversaciones ● Establecimiento de una sesión ● Transporte prepara las aplicaciones para su comunicación, mediante el almacenamiento y gestión de cierta información útil sobre la conversación que se va a producir. ● Entrega confiable ● Parte de la comunicación puede perderse. Transporte puede recuparar la parte perdida. ● Entrega en orden ● La llegada de los datagramas puede tener un orden diferente al de salida, dadas las diferentes rutas que pueden seguir. Transporte garantiza el reensamblado en orden correcto. ● Control del flujo ● Adaptación al host más limitado para evitar pérdidas debidas a su saturación.

8 4.1.3.1. Soporte de comunicación confiable. ● Operaciones básicas de confiabilidad: ● Seguimiento de los datos transmitidos. ● Acuse de recibo de los datos transmitidos. ● Retransmisión de cualquier dato sin confirmar. ● La confiabilidad tiene un coste: el tráfico de control. ● A mayor cofiabilidad, mayor coste. ● Buscar compromiso entre confiabilidad y eficiencia dependiendo de la aplicación. ● Algunas aplicaciones necesitan un confiabilidad total: – Bases de datos. – Correo electrónico – Páginas web, transacciones comerciales... ● Otras se pueden permitir la pérdida parcial de sus datos: – Stream de video. – Voz

9 4.1.4.1. TCP y UDP ● TCP y UDP son los protocolos más comunes de transporte. ● UDP (User Datagram Protocol) ● Protocolo mínimo; prácticamente solo incluye puerto de origen y destino. ● Mejor intento (no confiable). ● DNS, VoIP y streaming de video. ● TCP (Transmission Control Protocol) ● Orientado a la conexión. ● Orden de entrega, entrega confiable y control del flujo. ● 20 bytes de carga en el encabezado (UDP solo 8). ● Ver encabezados en CCNA.

10 4.1.5.1. Direccionamiento del puerto ● Identificación de conversaciones. ● Puerto de origen: puerto asociado a la aplicación de origen. ● Puerto de destino: puerto asociado a la aplicación de destino. ● Puertos de aplicaciones servidor: definidos estáticamente por la IANA. El servidor conoce su número de puerto. ● Puertos de aplicaciones cliente: definidos dinámicamente. La aplicación elige un puerto que no esté siendo usado. ● El puerto de destino se puede modificar. Por ejemplo: – http://www.google.com:443 http://www.google.com:443 ● La cominación IP + nº de puerto identifica de manera única a una aplicación en una red. Se le denomina Socket. Ej. – 192.168.4.31:80 ● Dos socketes identifican una conversación.

11 4.1.5.2. Direccionamiento del puerto. ● La IANA asigna los números de puerto. ● http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/port-numbers ● Puertos well-known: – desde el 1 al 1023. – Corresponden a aplicaciones muy conocidas y controladas (HTTP, POP, SMTP, Telnet, SSH, SMB...) ● Puertos registrados: – Del 1024 a 49151. – Aplicaciones del usuario. Elegidos dinámicamente. – Algunas aplicaciones servidor no Well-known. ● Puertos efímeros: – Del 49 152 al 65 535. – Usados temporalmente para ciertas operaciones. ● Algunas aplicaciones utilizan puertos TCP y UDP. Depende de la conversación. Por ejemplo DNS.

12 4.1.5.3. Direccionamiento del puerto ● Para conocer las conexiones activas en un host usamos el comando “netstat”. ● Cada conexión TCP significa: ● Conexión desde el exterior. ● Consumo de recursos. ● Las conexiones innecesarias o inexplicables deben replantearse.

13 Comando Netstat ● http://www.estrellateyarde.org/so/netstat-en-linux http://www.estrellateyarde.org/so/netstat-en-linux ● Man netstat ● http://technet.microsoft.com/en-us/library/bb490947.aspx http://technet.microsoft.com/en-us/library/bb490947.aspx ● Netstat /?

14 4.1.6.1. Segmentación y reensamblaje. ● Dividir los datos de aplicación en secciones garantiza que los datos se transmitan dentro de los límites del medio y que los datos de distintas aplicaciones puedan ser multiplexados en el medio. ● TCP da información sobre: ● Origen y destino ● Orden de secuencia ● Segmentos recibidos ● Control del flujo y administración de la saturación ● UDP da información sobre: ● Origen y destino

15 Práctica

16 4.2.1.1. Cómo generar conversaciones confiables ● Conexión ● Antes de que un host envíe datos a otro: – TCP establece una conexión en ambas direcciones. – La conexión permite el rastreo de la conversación ya que ambos extremos tienen constancia de la conversación. – Iniciada la conversación de envían acuses de recibo por cada segmento recibido. – Al recibir un acuse de recibo de un segmento, deja de rastrearse el segmento. En caso contrario, se reenvía el segmento. – Establecimientos de conexión + acuses de recibo + retransmisiones = carga adicional. – No solo hay carga en la red. El seguimiento de segmentos y acuses de recibo tienen coste computacional. – Todo esto es posible gracias a los campos de TCP.

17 4.2.2.1. Procesos del servidor TCP. ● Los procesos (de aplicación) del servidor esperan una solicitud de información u otro servicio. ● Administrador configura proceso para escuchar en un puerto. ● No pueden haber dos procesos servidor escuchando en el mismo número de puerto dentro de los mismos servicios de la capa de Transporte. ● La asignación de un puerto a una aplicación de servidor que está activo deja el “puerto abierto”. ● Si un puerto está abierto, TCP acepta las conexiones al socket y las dirige a la aplicación de servidor correspondiente. ● Normalmente un servidor (físico) tiene varios puertos abiertos.

18 4.2.3.1. Establecimiento y finalización de la conexión TCP ● Inicio de la conexión: ● Intercambio de señales de 3 vías (3 handshake). – Establece que el dispositivo de destino esté presente en la red. – Verifica que el dispositivo de destino tenga un servicio activo y esté aceptando las peticiones en el número de puerto de destino que el cliente que lo inicia intente usar para la sesión. – Informa al dispositivo de destino que el cliente de origen intenta establecer una sesión de comunicación en ese número de puerto. ● Pasos: – Origen: Envía SYN + nº de secuencia origen (SeqOr_0) – Destino: Envía SYN ACK + SeqOr_0+1 + nº de sencuencia destino (SeqDes_0) – Origen: Comprueba SeqOr+1. Envía ACK + SeqOr_0+1 + SeqDes_0+1. ● Campos de control (1 bit cada uno): ● URG – Urgente. ● ACK – Acuse de recibo. ● PSH – Empuje (vaciar buffer) ● RST – Reset = reconfiguración de conexión. ● SYN – Sincronizar ● FIN – No hay más datos desde el emisor. ● Cuando uno de los campos está a 1, indica que información de control incluye el segmento.

19 4.2.4.1. Análisis del 3-Handshake con Wireshark. ● Analizar con Wireshark una conexión a un servidor web. ● Ver transparencia CCNA: ● 4.2.4.1 ● 4.2.4.2 ● 4.2.4.3

20 4.2.5.1. Terminación de una sesión TCP ● Dos sesiones: ● Del cliente al servidor ● Del servidor al cliente ● El cliente envía FIN y el servidor confirma con ACK la recepción. El cliente finaliza la sesión. ● El servidor enfía FIN y el cliente confirma con ACK la recepción. El servidor finaliza la sesión.

21 4.2.5.2. Actividad con PT

22 4.3.1.1. Reensamblaje de segmentos TCP ● Número de secuencia inicial (ISN). ● Los segmentos se enumeran y etiquetan secuencialmente en el origen. ● En el destino se comprueba que los segmentos llegan en orden. ● Cuando un segmento llega en orden no contiguo se almacena en un buffer en espera de que lleguen los segmentos perdidos. ● Cuando llegan los segmentos perdidos, se procesan junto con los que estaban en espera en el buffer.

23 4.3.2.1. Acuse de recibo de TCP con uso de ventanas. ● El número de secuencia y de acuse de recibo indica el número de bytes contenidos en los segmentos: ● Nº de secuencia: Nº relativo de bytes que han sido transmitidos en esta sesión más 1. ● Nº de reconocimiento: indica el siguiente byte que el receptor espera en esta sesión (acuso de recibo de expectativa). ● El origen entiende que se han recibido todos los bytes enviados y envía el siguiente lote, utilizando como número de secuencia el nº de acuse de recibo. ● En vez de enviar un acuse de recibo por cada byte, las confirmaciones van por lotes. ● Por ejemplo, si se comienza con un número de secuencia 2000, si se reciben 10 segmentos de 1000 bytes cada uno, se devolverá al origen un número de reconocimiento igual a 12001. ● Para saber hasta cuando puede esperar el destino para enviar un acuse de recibo se usa una ventana: ● El tamaño de ventana indica la cantidad de datos que un origen puede transmitir antes de que un acuse de recibo deba ser recibido. ● El tamaño de ventana se indica en el encabezado.

24 4.3.3.1. Manejo de la pérdida de segmentos. ● Solo se confirman los datos de los segmentos contiguos: ● Si se reciben los segmentos con números de secuencia de 1500 a 3000 y de 3400 a 3500, el número de acuse de recibo será 3001. ● Al no recibir confirmación, el origen vuelve al último acuse de recibo y retransmite desde aquí. ● Implementación típica: – Origen envia segmento y lo pone en cola. – Inicia un temporizador. – Si no recibe confirmación antes del timeout reenvía el segmento. ● Acuse de recibo selectivo: – Confirmación de segmentos discontínuos. – Reenvío solo de los segmentos perdidos. ● Ver animación.

25 4.3.4.1. Control de la congestión ● Al recibir confirmación el origen entiende que puede seguir enviando. ● El tamaño de ventana indica cuantos segmentos se envian antes de una confirmación. ● El tamaño de ventana se acuerda durante la conexión. ● TCP se ajusta al máximo que puede transmitir. ● Ver gráfico (ventana 3 KB)

26 4.3.4.2. Reducción del tamaño de la ventana. ● Recursos limitados en el host. ● Reducción de la ventana: – Disminución de la tasa de transmisión debido a que el origen espera acuses de recibo con más frecuencia. – Ver gráfico. ● Después de periodos sin pérdidas o recursos limitados: – Aumento progresivo de la ventana. – Aumenta hasta que vuelvan a haber pérdidas. ● Proceso de aumento y reducción contínuo, hasta encontrar el tamaño óptimo. ● Redes eficientes → Ventana grande. ● Redes ineficientes o sobrecargadas → Ventana pequeña. ● Ver gráfico.

27 4.4.1.1. UDP. Baja sobrecarga vs. confiabilidad ● No orientado a la conexión. ● No retransmite. ● No secuencia. ● No controla el flujo. ● Si se necesitan estas características, se pueden implementar aparte. ● DNS, SNMP, DHCP, RIP, TFTP, juegos online. ● Para aplicaciones donde un retraso es peor que la pérdida de datos.

28 4.4.2.1. Reensamblaje de datagramas de UDP ● No hay conexión. Cuando una aplicación está preparada para enviar datos, los envía (UDP orientado a transacción). ● Los fragmentos UDP son llamados datagramas (igual que los paquetes de red). ● UDP no ordena ni controla pérdidas. Sencillamente reensambla los datos de los datagramas que llegaron, en el orden en que llegaron y se los pasa a la aplicación. ● Si el orden es importante, corre de cuenta de la aplicación.

29 4.4.3.1. Procesos y solicitudes del servidor UDP. ● Las aplicaciones UDP también tiene asociados números de puerto well-known o registrados. ● Cuando UDP recibe un datagrama destinado a cierto puerto, le envía los datos a la aplicación servidor asociada. ● Ej: UDP 53 → DNS; UDP 1812 → RADIUS.

30 4.4.4.1. Procesos de cliente UDP ● La aplicación cliente elige un puerto al azar para usar como nº de puerto origen. ● Determina el puerto destino (well-known o registrado). ● Elección azarosa del puerto origen: aporta seguridad al evitar la predecibilidad de puertos abiertos. ● Elegidos el puerto origen y destino, se adjuntan estos datos en todos los datagramas (en ambos sentidos, aunque con su posición invertida).

31 4.4.4.2. Actividad con PT.

32 4.5.1.1. Actividad con netstat

33 4.5.2.1. Actividad con Wireshark

34 4.5.3.1. Actividad con Wireshark

35 4.5.3.2. Actividad con PT