Cómo comprobar la sonda de ventana cero
Si se establece en un tiempo prolongado, la velocidad de retransmisión será lenta, la eficiencia será baja y el rendimiento será deficiente. Y más tiempos de espera provocarán más retransmisiones.
Además, el período de tiempo de espera varía de una red a otra y no se puede establecer un período de tiempo de espera inactivo. Sólo se puede configurar dinámicamente. Para establecer tiempos de espera dinámicamente, TCP introdujo RTT (tiempo de ida y vuelta), que es el tiempo que tarda un paquete en pasar desde que se envía hasta que se devuelve. De esta manera, el remitente sabe aproximadamente cuánto tiempo tomará y puede configurar fácilmente el tiempo de espera - RTO (tiempo de espera de retransmisión), lo que hace que nuestro mecanismo de retransmisión sea más eficiente. Esto suena simple, como si solo necesitara anotar t0 cuando el remitente envía el paquete y luego anotar t1 cuando el receptor devuelve la transmisión, por lo que RTT = t1 - t0. No es tan simple. Esto es sólo una muestra y no representa la situación general.
Algoritmo clásico
El algoritmo clásico definido en RFC793 es el siguiente: 1) Primero, muestree el RTT y escriba los últimos valores de RTT. 2) Luego realice el suavizado y calcule SRTT - RTT suavizado. La fórmula de cálculo es: (donde α toma un valor entre 0,8 y 0,9, el nombre en inglés de este algoritmo es media móvil ponderada exponencial y el nombre chino es media móvil ponderada) SRTT = ( α * SRTT ) + ((1- α ) * RTT) 3) Comience a calcular RTO: RTO = min [ UBOUND, max [ LBOUND, (β * SRTT) ] ] donde:
UBOUND es el tiempo de espera máximo, es decir, el valor límite superior
LBOUND es el tiempo de espera mínimo, es decir, el valor límite inferior
El valor β suele estar entre 1,3 y 2,0.
Algoritmo Karn/Partridge
Sin embargo, existe un problema fundamental en el algoritmo anterior al retransmitir: si se debe usar la primera vez y el acuse de recibo devuelto para el muestreo RTT, o si se debe usar la retransmisión. ¿Tiempo y tiempo de respuesta para el muestreo RTT? No importa qué extremo uses primero, encontrarás este problema. Como se muestra en la siguiente figura:
El caso (a) es que no se devuelve el acuse de recibo y se envía una retransmisión. Si cuenta el tiempo entre el primer envío y el ACK, obviamente el recuento es grande.
El caso (b) es que el ACK regresa lentamente y el tiempo de retransmisión no es mucho antes de que se devuelva el ACK. Si cuenta el tiempo que lleva retransmitir y el tiempo que tarda el ACK en regresar, el tiempo es más corto.
Entonces, en 1987, propusimos un algoritmo llamado algoritmo de Karn/Partridge. La característica más importante de este algoritmo es que ignora las retransmisiones y no muestrea el RTT de las retransmisiones (ya sabes, no es necesario). resolver un problema que no existe). Sin embargo, esto conduce a otro gran problema: si en algún momento la red parpadea y de repente se ralentiza, provocando un retraso relativamente grande, este retraso hará que todos los paquetes se retransmitan (porque el RTO anterior era más pequeño), por lo que las retransmisiones no No cuenta, el RTT no se actualizará, lo cual es un desastre. Por lo tanto, el algoritmo de Karn utiliza un truco: una vez que se produce una retransmisión, el valor RTO existente se duplica (este es el llamado retroceso exponencial)
Algoritmo de Jacobson/Karels
El primero Los dos algoritmos utilizan un "promedio móvil ponderado". La mayor desventaja de este método es que si hay una gran fluctuación en el RTT, será difícil de detectar porque está suavizado. Por lo tanto, en 1988 se introdujo un nuevo algoritmo llamado algoritmo de Jacobson/Karels (ver RFC6289). Este algoritmo introduce una factorización de la diferencia entre la última muestra de RTT y el SRTT suavizado.
La fórmula de cálculo es la siguiente (donde DevRTT representa la desviación RTT) SRTT= SRTT+ α(RTT- SRTT)DevRTT= (1-β)*DevRTT+ β*(|RTT-SRTT|)RTO= ?*SRTT + ?*DevRTT ( donde: en Linux, α = 0,125, β = 0,25, μ = 1, ? = 4 - estos son los "parámetros de ajuste" del algoritmo, nadie sabe por qué, simplemente funciona...). El algoritmo final se utiliza en el protocolo TCP actual (código fuente de Linux disponible en: Código fuente de Linux en: tcp_rtt_estimator).
Ventana deslizante TCP
Cabe señalar que si no comprende la ventana deslizante TCP, no comprende TCP. Como todos sabemos, TCP debe resolver los problemas de transmisión confiable y confusión de paquetes, por lo que TCP debe comprender el ancho de banda de procesamiento de datos real o la velocidad de procesamiento de datos de la red para evitar la congestión de la red y la pérdida de paquetes. Por lo tanto, TCP ha introducido muchas tecnologías y diseños para el control del flujo de la red, y la ventana deslizante es uno de ellos. Como dijimos antes, el encabezado TCP tiene un campo llamado Ventana, también llamado Ventana Anunciada. Este campo es donde el extremo receptor le dice al extremo emisor cuántos datos puede recibir su búfer. Por lo tanto, el extremo emisor puede enviar datos de acuerdo con las capacidades de procesamiento del extremo receptor sin que el extremo receptor procese los datos. Para ilustrar la ventana deslizante, necesitamos observar algunas estructuras de datos del búfer TCP: En la figura anterior, podemos ver:
El extremo receptor LastByteRead apunta a la ubicación donde está el búfer TCP. leído, y NextByteExpected apunta a la última posición recibida de los paquetes de datos consecutivos, LastByteRcved apunta a la última posición de un paquete de datos recibido, también podemos ver que hay algunos datos en el medio que aún no han llegado, por lo que hay un área en blanco de datos.
El LastByteAcked del remitente apunta a la ubicación del Acked del receptor (lo que indica que el acuse de recibo se envió correctamente), LastByteSent indica que el acuse de recibo exitoso se envió pero aún no se ha recibido, y LastByteWritten apunta a la ubicación donde está escribiendo la aplicación superior.
Por lo tanto:
El receptor informará su propia AdvertisedWindow = MaxRcvBuffer - LastByteRcvd - 1 al remitente en el ACK
El remitente utilizará este tamaño de ventana; de acuerdo con Controlar los datos que se envían para garantizar que la parte receptora pueda procesarlos.
El siguiente es un diagrama esquemático de la ventana deslizante del remitente:
(Fuente de la imagen)
La imagen de arriba está dividida en cuatro partes, a saber (la ventana negra el modelo es la ventana deslizante)
#1 Confirme los datos recibidos del acuse de recibo.
#2 Los datos enviados aún no han recibido confirmación.
#3 Enviar en una ventana que aún no se ha enviado (aún hay espacio en el receptor).
#4 Datos fuera de la ventana (el receptor no tiene espacio)
Aquí hay una escala móvil (36 respuestas recibidas, 46-51 bytes enviados): El siguiente es un ejemplo del control del receptor el remitente:
(Fuente de la imagen)
Ventana cero
En la imagen de arriba, podemos ver que el servidor más lento es Cómo reducir la ventana deslizante de TCP a 0.
En este punto, debes preguntarte, ¿qué sucede con TCP si la ventana cae a 0? ¿El remitente no envía los datos? Sí, el remitente no enviará datos, puede pensar en ello como "cierre de ventana", entonces también debe preguntar, si el remitente no envía datos, el receptor tendrá temporalmente el tamaño de la ventana disponible, ¿cómo notificar al remitente?
Para solucionar este problema, TCP utiliza la tecnología Zero Window Probe (Zero Window Probe), denominada ZWP, es decir, el remitente envía un paquete ZWP al receptor para obtener el tamaño de la ventana del receptor. Por lo general, se configura 3 veces, la primera vez es de aproximadamente 30 a 60 segundos (dependiendo de la implementación). Si sigue siendo 0 después de 3 veces, algunas implementaciones de TCP enviarán un RST para romper el enlace.
Nota: Los ataques DDoS pueden ocurrir dondequiera que haya un lugar para esperar, y Zero Window no es una excepción. Algunos atacantes, después de usar HTTP para construir una cadena y enviar una solicitud GET, establecerán la ventana en 0, momento en el cual el servidor solo puede esperar a ZWP, por lo que el atacante enviará una gran cantidad de dichas solicitudes al mismo tiempo. agotando así los recursos del servidor. (Para obtener más información sobre este ataque, puede consultar la entrada de Wikipedia sobre SockStress)
Además, en Wireshark puede filtrar paquetes usando tcp.analysis.zeroo_window y luego, en el menú contextual, seguir la secuencia TCP. Paquetes ZeroWindowProbe y ZeroWindowProbeAck.
Síndrome de la ventana tonta
El síndrome de la ventana tonta se traduce como "síndrome de la ventana caótica". Como se muestra arriba, si nuestro receptor está ocupado recibiendo datos en la ventana de recepción, hará que el transmisor se vuelva cada vez más pequeño. Finalmente, si el receptor libera algunos bytes y le dice al remitente que ahora hay una ventana de cuántos bytes hay, nuestro remitente enviará estos bytes sin pensar. Ya sabes, nuestro encabezado TCP + IP tiene 40 bytes y no es rentable agregar tanta sobrecarga por unos pocos bytes.
Además, debe saber que hay una MTU en la red. Para Ethernet, la MTU es de 1500 bytes. Después de eliminar los 40 bytes del encabezado TCP+IP, la transmisión de datos real puede alcanzar. 1460, que es el llamado MSS (tamaño máximo de segmento), tenga en cuenta que el RFC de TCP define el valor predeterminado de este MSS como 536, porque RFC 791 estipula que el valor predeterminado de MSS es 536. RFC 791 establece que cualquier dispositivo IP debe recibir un tamaño de paquete mínimo de 576 (en realidad, 576 es la MTU para acceso telefónico a redes). Si sus paquetes de red pueden llenar la MTU, entonces puede usar todo el ancho de banda; de lo contrario, está desperdiciando ancho de banda. (Existen dos métodos de procesamiento para paquetes de datos más grandes que la MTU, uno es descartarlos directamente y el otro es volver a empaquetarlos y enviarlos en trozos). Puede pensar en MTU como el número máximo de personas que puede acomodar un avión. MTU es más eficiente si el avión está lleno; MTU es sin duda más caro si solo hay una persona en el avión. Entonces, el "síndrome de la ventana del tonto" es como tener sólo una o dos personas en un avión con capacidad para 200 personas. Resolver este problema no es difícil, simplemente evite responder a tamaños de ventana pequeños hasta que haya un tamaño de ventana lo suficientemente grande para responder, y esta idea puede ser implementada tanto por el remitente como por el receptor.