Para cada paquete enviado por el cliente, el servidor debe tener una respuesta, si el servidor no responde durante un cierto período de tiempo, el cliente reenviará el paquete hasta que haya una respuesta.
Para garantizar el orden, cada paquete tiene una identificación. Al establecer una conexión, se acordará la ID inicial y luego se enviará una por una de acuerdo con la ID. Para asegurar que no se pierda ningún paquete se debe responder a todos los paquetes enviados, sin embargo esta respuesta no llega uno por uno, sino que responderá a un determinado ID previo, indicando que todos han sido recibidos, este modo se llama acumulativo. confirmación o respuesta acumulativa (acuse de recibo acumulativo).
Para registrar todos los paquetes enviados y recibidos, TCP también requiere cachés en el remitente y el receptor para guardar estos registros. La memoria caché del remitente se organiza una por una según el ID del paquete y se divide en cuatro partes según la situación de procesamiento.
1. Enviado y confirmado. Esta parte es la que les diste a tus subordinados y ya está completa, por lo que debes tacharla.
2. Enviado pero aún no confirmado. Esta parte es lo que has asignado a tus subordinados pero aún no se ha completado. Debes esperar la respuesta completa antes de poder tacharla.
3. No enviado, pero ya esperando ser enviado. Esto es algo que aún no has entregado a tus subordinados, pero lo harás pronto.
4. No ha sido enviado ni será enviado todavía. Esto es algo que aún no has entregado a tus subordinados y no se lo darás todavía.
En TCP, el extremo receptor informará el tamaño de una ventana al extremo emisor, llamada ventana anunciada. El tamaño de esta ventana debe ser igual a la segunda parte más la tercera parte de arriba, es decir, las cosas que se han explicado pero no se han completado más las cosas que se explicarán próximamente. Si excede esta ventana, el extremo receptor no puede manejarlo y no puede enviarlo.
Para el receptor, el contenido registrado en su caché es más sencillo.
1. Aceptado y confirmado. Es decir, lo que me asignó mi jefe y lo cumplí.
2. Aún no lo he recibido, pero lo recibiré pronto. Esa es la carga de trabajo máxima que puedo aceptar.
3. Aún no ha sido aceptado y no puede aceptarse. Es decir, la parte que excede la carga de trabajo no se puede completar.
AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)。
Un método es esperar y reintentar, es decir, configurar un temporizador para cada paquete que se envía pero no tiene ACK, si excede un cierto tiempo, lo intentará nuevamente. Pero ¿cómo evaluar este tiempo de espera? Este tiempo no debe ser demasiado corto y debe ser mayor que el tiempo de ida y vuelta RTT, de lo contrario provocará retransmisiones innecesarias. No debe ser demasiado largo, de lo contrario el tiempo de espera será mayor y el acceso será más lento.
Para estimar el tiempo de ida y vuelta, TCP necesita tomar una muestra del tiempo RTT y luego realizar un promedio ponderado para calcular un valor, y este valor debe continuar cambiando porque las condiciones de la red cambian constantemente. Además de muestrear RTT, también se debe muestrear el rango de fluctuación de RTT para calcular un tiempo de espera estimado. Dado que el tiempo de retransmisión cambia constantemente, lo llamamos algoritmo de retransmisión adaptativa.
La política de TCP es duplicar el intervalo de tiempo de espera. Siempre que se encuentra una retransmisión de tiempo de espera, el siguiente intervalo de tiempo de espera se establece en el doble del valor anterior. Dos tiempos de espera indican que el entorno de la red es deficiente y no es apropiado realizar envíos frecuentes y repetidos.
Existe un mecanismo para la retransmisión rápida. Cuando el receptor recibe un segmento con un número de secuencia mayor que el siguiente esperado, detectará una brecha en el flujo de datos, por lo que enviará un ACK redundante, pero ACK es el segmento del mensaje que se espera que envíe. ser recibido. Cuando el cliente recibe tres ACK redundantes, retransmitirá el segmento perdido antes de que expire el temporizador.
LastByteSent - LastByteAcked <= min {cwnd, rwnd}, la ventana de congestión y la ventana deslizante controlan conjuntamente la velocidad de envío.
Para la red, la capacidad del canal = ancho de banda × retardo de ida y vuelta.
Cuando se inicia una conexión TCP, cwnd se establece en un segmento y solo se puede enviar un segmento a la vez; cuando se recibe esta confirmación, cwnd se incrementa en uno, por lo que se pueden enviar dos a la vez; cuando llegan las dos confirmaciones , cada El cwnd de cada confirmación se incrementa en uno y el cwnd de dos confirmaciones se suma en dos, por lo que se pueden enviar cuatro a la vez; cuando llegan las cuatro confirmaciones, el cwnd de cada confirmación se suma en uno y el cwnd de cuatro confirmaciones se suma a cuatro, por lo que se pueden enviar ocho a la vez. Se puede ver que se trata de un crecimiento exponencial.
¿Cuándo terminará el ascenso? Hay un valor de ssthresh de 65535 bytes, cuando excede este valor hay que tener cuidado, no puede bajar tan rápido, puede estar casi lleno y volver a ralentizarse.
Después de recibir cada confirmación, cwnd aumenta en 1/cwnd. Continuamos con el proceso anterior y enviamos ocho a la vez. Cuando llegan ocho confirmaciones, cada confirmación aumenta en 1/8 y el cwnd total de las ocho confirmaciones aumenta en 1. entonces poder enviar nueve a la vez se convirtió en un crecimiento lineal.
Una forma de congestión es la pérdida de paquetes, que requiere tiempo de espera y retransmisión. En este momento, configure sshresh en cwnd/2, configure cwnd en 1 y reinicie el inicio lento. Es cierto que una vez que se retransmite el tiempo de espera, volverá inmediatamente al estado anterior a la liberación. Pero este método es demasiado radical: si una velocidad de transmisión de alta velocidad se detiene repentinamente, provocará que la red se congele.
Algoritmo de retransmisión rápida. Cuando el extremo receptor descubre que se ha perdido un paquete intermedio, envía el ACK del paquete anterior tres veces, por lo que el extremo emisor retransmitirá rápidamente sin esperar el tiempo de espera antes de retransmitir. TCP cree que esta situación no es grave, porque la mayor parte no se pierde, solo una pequeña parte se pierde, cwnd se reduce a la mitad a cwnd/2, luego sshthresh = cwnd, cuando se devuelven tres paquetes, cwnd = sshthresh + 3, es decir No volvió a ser el nivel anterior a la liberación de la noche a la mañana, pero todavía tenía un valor relativamente alto y creció linealmente.
Los dos fenómenos que el control de congestión TCP está diseñado principalmente para evitar son problemáticos.
El primer problema es que la pérdida de paquetes no significa que el canal esté lleno, también puede ser que la tubería tenga una fuga. Por ejemplo, si el ancho de banda de la red pública no está lleno, los paquetes se perderán, en este momento se considerará congestionado y se retirará, lo que en realidad está mal.
El segundo problema es que el control de congestión de TCP espera hasta que los dispositivos intermedios estén llenos antes de que se produzca la pérdida de paquetes, lo que reduce la velocidad. Para entonces, ya es demasiado tarde. De hecho, TCP solo necesita llenar la tubería y no debería continuar llenándose hasta que también se llene el caché.
Algoritmo de congestión TCP BBR . Intenta encontrar un punto de equilibrio, que consiste en llenar la tubería acelerando continuamente la velocidad de envío, pero sin llenar el caché del dispositivo intermedio, porque el retraso aumentará. En este punto de equilibrio, se puede lograr un alto ancho de banda y una baja latencia. Bueno, saldo extendido.
Este artículo es una nota de estudio del día 12 de septiembre. El contenido proviene del "Protocolo de Internet" de Geek Time . Se recomienda este curso.