Resumen de TCP

Título: Resumen de TCP

Fecha: 2018-03-25 09:40:24

Etiqueta:

Categoría:

p>

- Red de Computadoras

Todos sabemos que TCP es un protocolo ubicado en la capa de transporte, y tiene otro hermano, UDP. Los dos juntos forman el transporte. capa. Obviamente, existe una gran diferencia entre ellos, de lo contrario la capa de transporte solo necesitaría un protocolo.

?Una de las diferencias más importantes es que uno está orientado a la conexión y el otro no. Esta diferencia lleva a si pueden garantizar una transmisión estable. Obviamente, no hay forma de garantizar UDP. que no está orientado a la conexión La transmisión confiable solo puede ser garantizada por la capa de red subyacente y la capa de enlace. Todos sabemos que la capa de red utiliza el protocolo IP no confiable. Entonces, la capa de red no puede garantizar una transmisión confiable, por lo que UDP depende de la capa de enlace para garantizar una transmisión confiable.

TCP no solo cuenta con el soporte de la capa de enlace subyacente, sino que también tiene sus propios servicios orientados al enlace para garantizar la confiabilidad de la transmisión. Por supuesto, TCP no es sólo un método de transporte más confiable que UDP, como se mencionó anteriormente, esta es solo una diferencia importante entre ellos. De hecho, existen tres características importantes que diferencian a TCP de UDP.

?* Transmisión confiable

?* Control de flujo

?* Control de congestión

TCP tiene principalmente un mecanismo de retransmisión de confirmación y calibración de datos. A continuación se incluye una introducción detallada a estos métodos para garantizar una transmisión confiable.

La retransmisión confirmada, en pocas palabras, significa que el receptor envía una respuesta ACK al remitente después de recibir el mensaje, lo que indica que se han recibido los datos enviados por el remitente. Si el remitente no recibe un ACK del receptor después de esperar un cierto período de tiempo, el remitente pensará que el paquete de datos se ha perdido y, si el receptor no recibe el paquete de datos, lo retransmitirá.

Bueno, el mecanismo anterior es relativamente fácil de entender, pero encontraremos un problema, es decir, si el receptor ha recibido los datos y luego se pierde el ACK devuelto, el remitente juzgará mal y provocará la retransmisión. . Entonces el receptor recibirá los datos redundantes, pero ¿cómo puede saber el receptor si los datos son redundantes o nuevos?

Esto implica otro mecanismo de TCP, es decir, el uso de números de secuencia y números de confirmación, es decir, cada vez que se envían datos, el segmento del mensaje incluye el número de secuencia del segmento del mensaje actual y. el mensaje anterior. Número de confirmación, para que el receptor pueda determinar si desea recibir segmentos de mensajes duplicados en función de los datos que ya están en la memoria caché del receptor. En este momento, si se produce una pérdida de ACK como se describe anteriormente, lo que resulta en la recepción de segmentos de información duplicados, el cliente descartará los segmentos de información redundantes.

Bien, ahora tenemos una comprensión general del mecanismo de retransmisión de confirmación, pero hay una cosa que aún no está clara y es cómo se implementa TCP.

Este es el primer problema que debemos resolver, es decir, cómo confirmar. Hay dos tipos de confirmaciones involucradas, a saber, confirmaciones acumulativas (confirmaciones de devolución) y protocolos de parada única.

Para entender esto, un diagrama sencillo consiste en realizar una confirmación cada vez que se envían datos. El remitente debe esperar hasta recibir un ACK antes de enviar los siguientes datos.

Usamos el mismo mecanismo ACK, pero cabe señalar que no reconocemos cada segmento de datos, solo reconocemos el último segmento de datos. Esta es una comparación de la información en la imagen de arriba. información anterior.

Resumen: en la figura anterior, podemos ver que la confirmación acumulativa es más eficiente. En primer lugar, tiene menos paquetes de confirmación, por lo que. Además, la mayor parte de la red necesita transmitir la mayor parte de los datos, en lugar de la mitad de los datos y la mitad del ACK. Luego podemos ver en la segunda imagen que podemos enviar múltiples segmentos continuamente (el número específico que se puede enviar). un tiempo depende de La ventana de envío está determinada por la ventana de recepción y la ventana de congestión).

Esta es la primera vez que veo una red con múltiples mensajes, ¡y se pueden enviar múltiples mensajes a la vez!

Conclusión: Obviamente, este último es el mejor enfoque, y las implementaciones de TCP utilizan naturalmente reconocimientos acumulativos.

El tiempo específico anterior es el tiempo de espera. ¿Por qué existe este valor? De hecho, el remitente inicia un temporizador al enviar datos y el valor inicial de este temporizador es el período de tiempo de espera.

El cálculo del tiempo de espera es un poco problemático, principalmente porque es difícil determinar un valor definido. Si es demasiado largo, la espera no tendrá sentido, y si es demasiado corto, conducirá. a paquetes de datos redundantes. Los diseñadores de TCP diseñaron una fórmula de cálculo del tiempo de espera, que es conceptualmente bastante problemático, pero aún así está bien hacerlo poco a poco.

En primer lugar, pensemos en cómo diseñar la fórmula de cálculo del tiempo de espera. El tiempo de espera generalmente está relacionado con el tiempo de transmisión de los datos y debe ser mayor que el tiempo de ida y vuelta. los datos (los datos viajan del remitente al receptor una vez. tiempo de uso). Entonces, comenzamos con el tiempo de ida y vuelta, pero otro problema es que el tiempo de ida y vuelta no es fijo, ¿cómo determinamos este valor? Naturalmente pensamos que podemos tomar el promedio del tiempo de ida y vuelta en un corto período de tiempo para representar el tiempo de ida y vuelta en este momento. ¡Esta es la idea del cálculo!

Bien, encontramos el tiempo de ida y vuelta (RTT), entonces el siguiente tiempo de espera debería ser el tiempo de ida y vuelta más un número para obtener el tiempo de espera. Este número también debe ser dinámico y lo elegiremos como la diferencia fluctuante en los tiempos de ida y vuelta, es decir, la diferencia entre dos tiempos de ida y vuelta adyacentes.

Aquí está nuestra fórmula de tiempo de espera estimado:

Bien, ya tienes un conocimiento básico de cómo se calcula el tiempo de espera. La fórmula no es perfecta, pero es la forma correcta de pensar en ella. . Echemos un vistazo a lo que hacen los implementadores de TCP.

Bueno, así es como TCP implementa los tiempos de espera, pero ese no es siempre el caso en aplicaciones reales. Si tenemos una red realmente mala y estamos perdiendo paquetes, no tenemos que calcularlo así, simplemente duplicamos el tiempo de espera original y lo usamos como nuevo tiempo de espera.

Resumen: Ok, ahora sabemos cómo calcular el tiempo de espera en ambos casos. En circunstancias normales, usaríamos la fórmula más compleja anterior, que es RTT + volatilidad; de lo contrario, duplicarla

p>

En lo anterior, vemos que. el remitente espera un tiempo de espera antes de retransmitir y luego retransmite nuevamente, pero el tiempo de espera que calculamos no siempre es exacto, lo que significa que una cosa que hacemos a menudo es esperar, y generalmente esperar un tiempo bastante largo. Entonces, ¿es posible optimizar esto?

Por supuesto, existe un método de optimización en la implementación de TCP, a saber, el mecanismo de retransmisión rápida que se describe aquí. La idea es que cuando el remitente reciba tres ACK redundantes, comience a retransmitir ese segmento. Entonces, ¿por qué tres ACK redundantes? Tenga en cuenta que tres ACK redundantes son en realidad cuatro ACK. Veamos la estrategia de transporte ACK especificada en el documento RFC 5681.

Bien, ahora podemos ver que si hay tres ACK redundantes, entonces el caso tres solo puede ocurrir dos veces, lo que significa que se envían dos datos más grandes de lo esperado. Sin embargo, tenga en cuenta que existen dos posibilidades para que se produzca el escenario 3: una es la pérdida de paquetes y la otra es la llegada desordenada.

Echemos un vistazo, suponiendo que los datos lleguen en el orden incorrecto.

La primera situación de desorden

La otra situación de desorden

Situación de pérdida de paquetes

Después de descubrir que Si se pierde el paquete de datos, necesitamos retransmitir el paquete de datos, pero también hay dos formas de retransmitir el paquete de datos, a saber, GBN y SR, es decir, retransmisión de retroceso y retransmisión selectiva. De hecho, ya podemos ver cómo funcionan por el nombre. La retirada y la retransmisión significa que cuando se confiscan los datos, todos los datos futuros se retransmitirán desde ese lugar. Esto es realmente muy sencillo de implementar, que consiste en mover la ventana de envío. y La ventana de recepción se abre, pero también descubrimos que este método no es práctico para hacer muchas cosas repetitivas y la eficiencia es muy baja.

Luego elige retransmitir, es decir, transferirlo a quien creas que lo ha perdido. No hay esfuerzo en vano.

Conclusión: TCP en realidad utiliza una combinación de los dos, es decir, reconocimiento selectivo, lo que significa que permite que el receptor TCP reconozca selectivamente la salida. -segmentos de red en orden en lugar de acumular el último segmento de red en orden aceptado correctamente. Es decir, omite la retransmisión de segmentos desordenados que han sido aceptados correctamente.

?La validación de datos es en realidad muy simple: consiste en verificar el encabezado y luego completar la validación de datos calculando checkSum y comparándolo con la validación de datos. .

?En UDP, UDP "arroja" datos directamente al otro puerto final de la capa de aplicación y básicamente no realiza ningún procesamiento. Entonces, si los datos que envía a la capa de red tienen más de 1500 bytes, que es mayor que la MTU, entonces la capa IP del remitente debe fragmentarse. Divida el datagrama en fragmentos para que cada fragmento sea más pequeño que la MTU. La capa IP receptora necesita volver a ensamblar el datagrama. Esto hará más cosas, y más en serio, debido a las características de UDP, cuando se pierde un dato transmitido, el receptor no puede volver a ensamblar el datagrama, lo que hará que se descarte todo el datagrama UDP.

?En TCP, MTU se dividirá razonablemente, es decir, existe un concepto llamado longitud máxima del segmento de mensaje (MSS) en TCP, que especifica la longitud máxima del segmento de mensaje TCP. Tenga en cuenta que esto no incluye el encabezado TCP, es decir, su valor típico es 1460 bytes (los encabezados TCP e IP ocupan cada uno 20 bytes). Dado que TCP tiene un número de secuencia y un número de confirmación, el receptor almacena en un buffer los datos que llegan desordenados y reordena los segmentos según el número de secuencia antes de entregarlos a la capa de aplicación.

?El control de flujo generalmente significa que cuando el receptor acepta el segmento de información, el programa de la capa superior en la capa de aplicación puede estar ocupado haciendo otras cosas y no tiene tiempo para procesar los datos en el caché. Si el remitente no controla la velocidad al enviar, es probable que el búfer de recepción se desborde, lo que provocará la pérdida de datos.

?Otra situación es la congestión de la red entre dos hosts. Si el remitente aún envía a una velocidad más rápida, se perderá una gran cantidad de paquetes de datos y el remitente deberá reducir la velocidad de envío.

Aunque parece que ambas situaciones anteriores hacen que el host emisor ralentice la velocidad de envío debido a la posibilidad de pérdida de datos, es importante separar estas dos situaciones porque la primera pertenece al control de flujo y este último control de congestión, esto será lo que tendremos que discutir más adelante. No confundas estos dos conceptos.

De hecho, cuando hablamos de control de flujo, tenemos que mencionar el protocolo de ventana deslizante, que es la base del control de flujo. Dado que las conexiones TCP son full-duplex, es decir, también aceptan durante el envío, tanto el remitente como el receptor mantienen ventanas de envío y recepción. En aras de la discusión, adoptamos aquí un enfoque unidireccional.

El receptor mantiene una ventana de recepción y el remitente mantiene una ventana de envío. Al enviar, necesita saber cuánto espacio queda en la ventana de recepción, es decir, los datos que envía no pueden exceder el tamaño de la ventana de recepción, de lo contrario se desbordará. Al recibir el ACK del receptor, podemos mover la ventana del receptor y deslizar los datos confirmados fuera de la ventana, y al mismo tiempo mover la ventana del remitente y deslizar los datos confirmados fuera de la ventana.

De esta manera, los tamaños de las dos ventanas pueden ser consistentes. Cuando el receptor no puede recibir datos, el tamaño de la ventana se ajustará a 0 y la ventana del remitente no enviará datos. Pero hay un problema. En este momento, cuando la ventana del receptor se ajusta nuevamente, no notificará activamente al remitente. Aquí, el remitente pregunta activamente.

?O haga un dibujo para verlo de manera más intuitiva:

?El control de la congestión generalmente es causado por la congestión causada por demasiados datos enviados por los hosts de la red. Las rutas congestionadas generalmente son una comparación de carga. Para un enrutamiento alto, para obtener una mejor estabilidad de la transmisión de datos en este momento, se debe utilizar el control de congestión. Por supuesto, también reduce la carga del enrutamiento y evita fallas.

?Aquí se presentan dos métodos principales de control de congestión, uno es el inicio lento y el otro se llama recuperación rápida.

Entonces la pregunta es, ¿por qué necesitas un número de serie? ¿Por qué tres apretones de manos en lugar de dos? ¿Qué es un ataque de inundación SYN?

Cabe señalar que el estado TIME_WAIT largo final suele ser para permitir que el cliente emita un ACK, lo que suele tardar 1 o 2 minutos

Bueno, ¿realmente escribí un? mucho, principalmente para descubrir la transmisión confiable y la gestión de conexión de TCP, así como los detalles, lo cual consumió mucho tiempo. Luego, la otra cosa que no se trata es el problema del encabezado TCP, que no se analiza en detalle. En realidad, esto no es difícil, pero ahora el espacio es muy grande, así que hagamos esto primero. así que no necesitas saber demasiado.