Red informática [de arriba hacia abajo] - capa de transporte

1. Principios de una transmisión de datos fiable

protocolo confiable de transferencia de datos (rdt)

En el caso de los servicios de mejor esfuerzo proporcionados por la capa inferior, se proporcionan servicios confiables a la capa superior a través de esta capa.

1. Deja de esperar el acuerdo

1.1, Rdt1.0 Transmisión de datos confiable en canales confiables

• El canal de capa inferior es completamente fiable.
  • No hay bits incorrectos
  • No se pierden paquetes
• FSM para remitente y receptor
  • El remitente envía datos al canal inferior.
  • El receptor recibe datos del canal de capa inferior.

1.2, canal Rdt2.0 con solo errores de bits

• El canal subyacente puede estar equivocado: invierta los bits del paquete

  • Utilice sumas de comprobación para detectar errores de bits

• Pregunta: Cómo recuperarse de errores:

  • Acuse de recibo (ACK): el receptor le dice explícitamente al remitente que el paquete se recibió correctamente.
  • Acuse de recibo negativo (NAK): el receptor le dice explícitamente al remitente que ocurrió un error en el paquete.
    • Después de que el remitente recibe el NAK, retransmite el paquete.

• Nuevo mecanismo en rdt2.0: detección de errores con codificación de control de errores

  • Enviar codificación y almacenamiento en caché del mecanismo de error de variación
  • El receptor utiliza la detección de errores de codificación
  • Comentarios del receptor: mensaje de control (ACK, NAK); receptor → remitente
  • El remitente toma las acciones correspondientes después de recibir los comentarios.

  Descripción del texto:
  El remitente envía datos en el pasado. Después de que el receptor recibe los datos, realiza la verificación de los datos;
  si no hay ningún problema, envía un ACK (confirmación) al remitente. Después de analizar los datos, proporciona los datos. a la capa superior a través de la interfaz anterior. ;
  Si la verificación falla, responda al remitente con un NAK (acuse de recibo inverso);
  después de que el remitente recibe el NAK, reenvía los datos originales hasta que recibe el ACK y luego continúa enviando los datos posteriores.

1.3, Rdt2.1: ACK/NAK con error del remitente

Se agrega una versión pkt sobre la base de rdt2.0, que puede repetirse (simplemente no entregarla a la capa superior), pero no saldrá mal.

Proceso rdt2.1:

• remitente:
  • Agregar número de serie al grupo
  • Dos números de secuencia (0, 1) son suficientes
    • Envíe solo un paquete no reconocido a la vez
  • Debe detectar si ACK/NAK es incorrecto (requiere EDC)
  • El número de estados se ha duplicado.
    • Es necesario recordar si el número de secuencia del grupo actual es 0 o 1
• receptor
  • Debe detectar si los paquetes recibidos son duplicados.
    • El estado indicará si el número de secuencia del paquete que desea recibir es 0 o 1
  • Nota: El receptor no sabe si el remitente recibió su ACK/NAK correctamente
    • Confirmación sin confirmación de programación

1.4, Rdt2.2: Protocolo sin NAK

La función es la misma que rdt2.1, pero solo falta una confirmación inversa NAK y el ACK (número de serie 0 y 1) se usa para la confirmación.

1.5, Rdt3.0: canal con errores de bits y pérdida de paquetes

• Nueva suposición: el canal subyacente puede perder paquetes (datos o ACK)
  • se estancará
  • Los mecanismos no son suficientes para afrontar esta situación.
    • suma de control
    • número de serie
    • ACK
    • Retransmisión
• Método: el remitente espera ACK durante un período de tiempo razonable
  • El remitente retransmite después del tiempo de espera: si no se recibe ACK para entonces → retransmitir
  • Problema: si el paquete (o ACK) simplemente se retrasa:
    • La retransmisión provocará la duplicación de datos, pero este problema ya se puede solucionar utilizando el número de secuencia.
    • El receptor DEBE especificar el número de secuencia que se recibió correctamente
  • Necesita un temporizador de cuenta regresiva
    

2. Protocolo de canalización

Canalización: permite al remitente enviar varios paquetes a la vez sin el reconocimiento del otro.

• Se debe aumentar el rango de números de serie: utilice varios bits para representar el número de serie del grupo
• Es necesario que haya un búfer en el lado del remitente/receptor.
  • Búfer del remitente: no reconocido, es posible que sea necesario retransmitirlo;
  • Caché del receptor: la velocidad a la que los usuarios de la capa superior acceden a los datos = la velocidad de los datos recibidos: los datos recibidos pueden estar desordenados y entregados en orden (se puede verificar)
• Dos protocolos de canalización comunes: retroceso N pasos (GBN) y retransmisión selectiva (SR)
  • GBN:RW=1, no se puede recibir fuera de servicio
  • SR: RW>1, los paquetes dentro de la ventana de recepción se pueden recibir desordenados, pero no se pueden entregar y la ventana de recepción no puede deslizarse hacia adelante.

2.1 Protocolo de ventana deslizante

• Enviar búfer:
  • Formulario: un área en la memoria donde se pueden enviar los paquetes que caen en el búfer
  • Función: se utiliza para almacenar paquetes que se han enviado pero no confirmados
  • Necesidad: Disponible cuando se requiere reenvío
• El tamaño del búfer de envío: la cantidad máxima de paquetes no reconocidos que se pueden enviar al mismo tiempo
  • protocolo-detener-esperar=1
  • Protocolo de canalización > 1, valor razonable, no puede ser muy grande, la utilización del enlace no puede exceder el 100%
• enviar paquete de buffer
  • Lo que no ha sucedido : los paquetes que caen en el búfer de envío pueden enviarse continuamente.
  • Grupos que han sido enviados y están esperando la confirmación de la otra parte: los grupos en el búfer de envío solo se pueden eliminar después de haber sido confirmados.

Similitudes y diferencias entre el acuerdo GBN y el acuerdo SR

• similitudes
  • enviar ventana > 1
  • Se pueden enviar varios paquetes no reconocidos a la vez
• la diferencia
  • GBN: tamaño de ventana de recepción = 1
    • Receptor: solo puede recibir secuencialmente
    • Remitente: desde el punto de vista del rendimiento, una vez que un paquete no se envía correctamente, como: 0, 1, 2, 3, 4
      • Si 1 no tiene éxito, se envían 2, 3 y 4, se devuelve 1 y luego se genera GBN
  • SR: tamaño de ventana de recepción > 1
    • Final de recepción: puede recibir fuera de servicio
    • Final de envío: envíe 0, 1, 2, 3, 4, una vez que 1 no tenga éxito, se haya enviado 2, 3, 4, no es necesario reenviar, envíe 1 selectivamente

Retroceder N pasos GBN

Seleccione retransmitir SR

2. Multiplexación

1. Servicios y protocolos de transmisión

• Proporciona comunicación lógica entre procesos de aplicaciones que se ejecutan en diferentes hosts.
• El protocolo de transporte se ejecuta en el sistema final.
  • Remitente: divida el mensaje de la capa de aplicación en segmentos de mensaje y luego páselos a la capa de red
  • Receptor: vuelva a ensamblar el segmento del mensaje en un mensaje y luego páselo a la capa de aplicación
• Hay múltiples protocolos de capa de transporte disponibles para que las aplicaciones elijan
  • Internet: TCP y UDP

2. Capa de transporte VS capa de red

• Servicios de capa de red: comunicación lógica entre hosts
• Servicios de capa de transporte: comunicación lógica entre procesos.
  • Servicios que dependen de la capa de red.
    • Latencia, ancho de banda
  • Y mejorar el proceso de servicio de la capa de red.
    • Pérdida de datos, confusión, cifrado.

Pase hacia abajo a través de Socket para agregar datos de encabezado y finalmente páselo al objetivo a través de la tarjeta de red y luego demultiplexelo.

3. Multiplexación/Demultiplexación

• multiplexado en el host del remitente
  • Reciba mensajes de múltiples procesos desde múltiples sockets y encapsule los segmentos de mensajes con encabezados según la dirección IP y el número de puerto correspondiente al socket (la información del encabezado se utiliza para la demultiplexación posterior)
• Demultiplexación en el host del receptor
  • El segmento de mensaje recibido se envía al socket correcto (y al proceso de aplicación correspondiente) según la dirección IP y el número de puerto en la información del encabezado del segmento de mensaje.

3. Transmisión UDP sin conexión

• Es posible que se pierdan segmentos de servicio de mejor esfuerzo
  • perdido
  • Los segmentos enviados al proceso de solicitud están desordenados
• UDP se utiliza para:
  • Streaming (insensible a pérdidas, sensible a tasas)

1. UDP: Protocolo de datagramas de usuario

¿Por qué UDP?

• No establezca una conexión (aumentará el retraso)
• Simple: no existe un estado de conexión entre el remitente y el receptor
• Los encabezados de segmento son pequeños (bajos gastos generales)
• Sin control de congestión y control de flujo.

4. Transporte orientado a conexión TCP

1.TCP: descripción general

• de igual a igual:

  • un remitente, un receptor

• Flujo de bytes confiable y en orden

  • sin Fronteras

• Tubería (canalización):

  • El control de congestión TCP y el control de flujo establecen el tamaño de la ventana

• Enviar y recibir caché

• Datos dúplex completo

  • Los datos fluyen en ambas direcciones en la misma conexión
  • MSS: tamaño máximo de segmento

• orientado a la conexión

  • Antes del intercambio de datos, las variables de estado del remitente y del receptor se inicializan mediante un protocolo de enlace (intercambio de mensajes de control)

• Con control de flujo:

  • El emisor no abrumará al receptor.
    

• Número de serie:

  • El número del primer byte del segmento de mensaje en el flujo de bytes.

• Número de confirmación

  • El número de secuencia del siguiente byte que se espera recibir de la otra parte.
  • confirmación acumulativa

• ¿Cómo maneja el receptor el estado fuera de servicio?

2. Retraso de ida y vuelta (RTT) de TCP y tiempo de espera

• Cómo configurar el tiempo de espera de TCP
  • más largo que RTT
    • Pero RTT está cambiando
  • demasiado corto: tiempo de espera demasiado pronto
    • retransmisión innecesaria
  • Demasiado largo: demasiado lento para responder a la pérdida de segmento, pasivo
• Cómo estimar el RTT
  • SampleRTT: Mide el tiempo desde que se envía un segmento de mensaje hasta que se recibe el acuse de recibo
    • Si hay retransmisión ignorar esta medida
  • SampleRTT variará, por lo que el RTT estimado debería ser más fluido
    • Promediar varias mediciones recientes en lugar de solo el SampleRTT actual

3. TCP: transmisión de datos confiable

• rdt establecido por TCP sobre la base de un rango de IP no confiable
  • segmento canalizado
    • GBN o SR
  • Confirmación acumulativa (como GBN)
  • Temporizador de retransmisión único (como GBN)
  • Si el desorden es aceptable, no existe un estándar
• La retransmisión se activa por los siguientes eventos
  • Tiempo de espera (reenviar solo el segmento más antiguo no reconocido: SR)
  • confirmación duplicada
    • Ejemplo: recibió ACK50, luego recibió 3 ACK50 más
• Consideremos primero el remitente TCP simplificado:
  • Ignorar confirmaciones duplicadas
  • Ignorar el control de flujo y el control de congestión

4. Gestión de conexiones TCP

Antes de intercambiar datos formalmente, el remitente y el receptor se dan la mano para establecer una relación de comunicación:

• Acepte establecer una conexión (cada parte sabe que la otra está dispuesta a establecer una conexión)
• Acordar los parámetros de conexión

Dos apretones de manos para establecer conexión.

• pregunta:
  • El servidor tendrá muchas medias conexiones.
  • Problema al recibir datos antiguos

5. Solución de protocolo de enlace de tres vías: problemas de semiconexión y recepción de datos antiguos

s: seleccione el número de secuencia inicial para decirle al servidor que el servidor lo ha recibido; luego dígale al cliente que lo ha recibido y también dígale al cliente el número de secuencia inicial del servidor; después de que el cliente reciba el número de secuencia inicial del servidor, luego le dice al servidor que ha recibido su número de secuencia inicial.

6. TCP cierra la conexión:

• El cliente y el servidor cierran respectivamente la conexión por su parte.
  • Enviar segmento TCP con bit FIN=1
• Una vez recibido FIN, responda con ACK
  • FIN recibido, ACK se puede enviar junto con su propio segmento FIN
• Puede manejar intercambios FIN simultáneos
• 

5. Control de congestión

1. Principio de control de la congestión

congestión:

• Definición informal: "Es necesario transmitir demasiados datos a través de la red, lo que excede las capacidades de procesamiento de la red".
• A diferencia del control de flujo
• Síntomas de congestión:
  • Pérdida de paquetes (desbordamiento del búfer del enrutador)
  • El paquete experimenta un retraso relativamente largo (haciendo cola en la cola del enrutador)
  • En la situación más grave, habrá un punto muerto en la red, solo la red entra pero no la red sale.

2. Método de control de la congestión

Dos métodos de control de congestión comúnmente utilizados:

• Control de congestión de extremo a extremo:
  • No hay comentarios de visualización de la red
  • Los sistemas finales infieren si hay congestión basándose en eventos de retraso y pérdida.
  • El método utilizado por TCP

• Control de congestión asistido por red: cajero automático
  • Los enrutadores proporcionan información de retroalimentación a los sistemas finales.
    • Se establece un solo bit para indicar congestión (SNA, DECbit, TCP/IP ECN AIM)
    • Muestra la tarifa que el remitente puede utilizar.

Control de congestión TCP:

conciencia de congestión

¿Cómo detecta el remitente la congestión?

• Se agotó el tiempo de espera de un segmento (evento de pérdida); congestión
  • El tiempo de espera expiró y la confirmación de un determinado segmento no llegó
  • Razón 1: Existe una alta probabilidad de congestión de la red (un búfer del enrutador no tiene espacio y se descarta)
  • Razón 2: Se descartaron errores (errores en todos los niveles, verificación fallida, descartados) la probabilidad es pequeña
  • Una vez que se agota el tiempo, se considera congestionado, hay un cierto error de juicio, pero la dirección general de control es correcta.
• 3 ACK duplicados sobre un segmento: ligera congestión
  • El primer reconocimiento del segmento, normal, confirma el segmento verde, espera el segmento rojo.

método de control de tasa

Cómo controlar la tarifa enviada por el remitente

• CongWin es dinámico y es una función de la congestión percibida de la red.
  • Tiempo de espera o 3 ataques repetidos, CongWin;
    • CongWin cae a 1 Mss cuando se agota el tiempo de espera, ingresa a la fase SS y luego se duplica a CongWin/2 (cada RTT), ingresando así a la fase CA
    • 3 ataques repetidos; CongWin degradado a CongWin/2, etapa CA

¿Por qué TCP es justo?

Dos sesiones TCP en competencia:

• La aditividad aumenta, la pendiente es 1, el rendimiento aumenta
• Reducción multiplicativa, el rendimiento disminuye proporcionalmente
•