¿Qué significa ventana TCP?
Cualquier parte puede cerrar la conexión TCP y requerir que ambas partes envíen una señal FIN para cerrar su canal de comunicación. Una parte puede cerrar antes que la otra o ambas partes pueden cerrar la conexión TCP al mismo tiempo. Por lo tanto, cuando una parte envía una señal FIN, la otra parte puede enviar un "FIN ACK" para comenzar a cerrar su propia comunicación y acusar recibo de la primera señal FIN. La persona que envió la primera señal FIN envía un mensaje "FIN ACK" para confirmar la recepción de la segunda señal FIN. La otra parte sabe que la conexión se ha cerrado y cierra la suya. La persona que envió el primer FIN no puede recibir el mensaje de confirmación de la última señal ACK. En este momento, ingresará al estado "TIME_WAIT" e iniciará un temporizador para evitar que la otra parte no reciba el mensaje ACK y piense que la conexión aún está abierta. Generalmente este estado dura de 1 a 2 minutos.
Ahora, analicemos la primera pregunta. Si alguien (si es un hacker) deja una conexión medio abierta en su servidor web, son malas noticias. Cada conexión consume memoria y abrir miles de conexiones TCP falsas puede provocar la caída del servidor. Por supuesto, no se puede ajustar el temporizador de TCP sin afectar el funcionamiento normal de TCP. Si ha oído hablar de un ataque TCP SYN, esto es lo que significa. Para evitar esto, la mayoría de los sistemas operativos limitan la cantidad de conexiones semiabiertas. Por ejemplo, el límite predeterminado para Linux suele ser 256.
En cuanto al tema del control de flujo continuo, lo discutiremos ahora. El mecanismo para implementarlo en TCP es el mecanismo de ventana deslizante de TCP. El protocolo TCP utiliza "retransmisión y reenvío ACK" para garantizar la confiabilidad de la transmisión de datos. El remitente esperará un período de tiempo. Si no recibe la información de confirmación ACK del paquete de datos que envió, lo reenviará. Por cierto, hay muchos temporizadores en el protocolo TCP. Este es sólo uno de los cronómetros. El concepto de ACK es muy importante para el control de flujo porque el protocolo de ventana deslizante TCP hace que el reconocimiento mutuo de TCP sea más eficiente. Si TCP envía un paquete y espera cada ACK, en realidad reduce el rendimiento de datos a la mitad.
Lo ideal sería enviar muchos paquetes a la vez y luego esperar un mensaje ACK para confirmar la recepción de todos los paquetes sin enviar más datos a la otra parte. Pero ¿cómo sabemos cuántos paquetes se han enviado? El tamaño de la ventana TCP controla cuántos paquetes pueden caber en el estado "enviado pero no reconocido". Si el tamaño de la ventana es grande, podemos enviar una gran cantidad de paquetes sin esperar información ACK. En realidad, esto es control de flujo.
El destinatario es la persona que controla el tamaño de la ventana. Si el receptor establece el tamaño de la ventana en "0", el remitente no podrá enviar ningún dato. Si el tamaño de esta ventana es "1", entonces volvemos al protocolo simple "enviar y esperar ACK". Si el último tamaño de ventana fue "0", el remitente enviará una señal de sonda para determinar cuándo se abrirá nuevamente la ventana. Si el remitente nunca recibe un mensaje ACK, seguirá intentándolo hasta que se agote el tiempo. Recuerde que el tamaño de la ventana es un campo de 16 bits en el encabezado TCP.
Si desea que el tamaño de la ventana (en bytes) sea mayor que lo que se puede representar con 16 bits (16 bytes son 2), también puede utilizar una opción del protocolo TCP llamada "escalado de ventana". Esta opción permite multiplicar el tamaño de la ventana por un factor de escala. Sin un tamaño de ventana muy grande, el protocolo TCP no puede aprovechar al máximo las conexiones de alta velocidad a nivel de gigabytes. Es por eso que necesitamos ajustar los parámetros TCP para estas nuevas conexiones de alta velocidad.
En cuanto al control de flujo TCP, cabe mencionar el algoritmo de Nagle. ¿Qué pasa si utilizamos una ventana TCP grande en la conexión telnet? Ingresarás un comando (como escribir una letra) y luego esperarás una respuesta, pero no aparecerá en el eco del terminal. Este es un gran problema para la comunicación en tiempo real. Además, Telnet también aumentará el grado de congestión de la red, porque un byte de datos (como nuestras pulsaciones de teclas) requiere 40 bytes de encabezados. Entonces, RFC 896 define este algoritmo de Nagle para eliminar paquetes pequeños. La idea es recopilar pequeños datos antes de enviarlos y luego enviarlos todos a la vez para mejorar la eficiencia. Para ser más eficiente, también se limita a permitir solo un segmento de datos no confirmado y no se pueden enviar más datos hasta que se obtenga la información de reconocimiento. Las conexiones Telnet y SSH interactivas utilizan la opción TCP_NODELAY de sockets de Windows para habilitar esta función, de modo que cuando presione una tecla, obtenga una respuesta inmediata.
Por supuesto, todavía ignoramos muchas cosas sobre el protocolo TCP. Sin embargo, a través de estos dos artículos, debería poder comprender algunos otros trabajos de TCP más profesionales. El control de bloqueo es diferente del control de flujo y el control de flujo no se analiza en este artículo. Si está realmente interesado en comprender cómo funciona el protocolo TCP, puede leer el RFC de TCP en detalle.
Resumen
El protocolo TCP es muy bueno para resolver problemas de control de flujo y, por lo tanto, es muy adecuado para muchas aplicaciones. El significado de control de flujo en el protocolo TCP es: "¿Cuántos datos puedo enviar antes de recibir la confirmación de que se han enviado?". Esta es la ventana TCP. El problema de aprender a controlar la congestión puede dejarse como ejercicio para el lector. Cabe señalar que bajo el protocolo TCP, la velocidad de conexión es muy lenta al principio y luego aumenta gradualmente. Este enfoque no siempre es ideal.