Se compilan y recopilan cuidadosamente explicaciones detalladas y análisis prácticos del protocolo TCP.

El protocolo TCP es un protocolo muy importante en la capa de transporte del modelo de protocolo TCP/IP, responsable de procesar la transmisión de datos entre los niveles de los puertos del host. Tiene principalmente las siguientes características:

1.TCP es un protocolo orientado a enlaces Antes de la transmisión de datos, se debe establecer un enlace TCP mediante un protocolo de enlace de tres vías. Cuando se completa la transferencia de datos. La conexión debe liberarse a través de cuatro ondas.

2. Cada comunicación TCP se realiza entre dos hosts y el host, y es un protocolo de transmisión punto a punto.

3.TCP proporciona servicios confiables, libres de errores, no perdidos, no duplicados y que llegan en orden.

4. Las partes de la comunicación TCP pueden enviar datos en cualquier momento cuando se establece la conexión. Ambos extremos de la conexión TCP están equipados con buffers de envío y buffers de recepción para almacenar temporalmente datos de comunicación bidireccional.

5. Orientado a flujo de bytes. Durante el proceso de transmisión de datos, si el mensaje es relativamente largo, TCP transmitirá los datos en segmentos. Cada información de transmisión TCP segmentada lleva un número de secuencia de segmento y cada segmento contiene una parte del flujo de bytes. El receptor realiza el empalme de datos en función de la información del número de secuencia transportada por cada segmento y finalmente empalma los datos de transmisión inicial. Sin embargo, durante todo el proceso de transmisión, cada segmento de TCP transporta datos de flujo de bytes cortados. Entonces TCP está orientado a flujos de bytes.

a.TCP y UDP utilizan métodos completamente diferentes a la hora de enviar mensajes. A TCP no le importa cuánto tiempo la aplicación envía el mensaje a la caché de TCP a la vez, sino que determina cuántos bytes debe contener un segmento de mensaje en función del valor de ventana proporcionado por la otra parte y el grado actual de congestión de la red. (UDP envía La longitud del mensaje la proporciona la aplicación).

b. Si el bloque de datos enviado por la aplicación al caché de TCP es demasiado grande, TCP puede dividirlo en fragmentos más cortos y luego transmitirlo. TCP también puede esperar hasta que se hayan acumulado suficientes bytes antes de construir un segmento y enviarlo.

Significado de cada campo:

Puerto de origen: el número de puerto del extremo emisor

Puerto de destino: el número de puerto del extremo receptor

Número de serie: TCP Al enviar un mensaje para transmisión segmentada, se agregará un número de secuencia a cada segmento. El extremo receptor también puede juzgar el orden de empalme de datos en función de este número de secuencia. problema de informes de red fuera de secuencia

Número de confirmación: el número de confirmación es el número de secuencia que el extremo receptor clasifica y confirma después de recibir los datos y envía la siguiente recepción esperada. Valor = número de transmisión recibida + 1 <. /p>

Desplazamiento de datos: 4 bits, que indica el comienzo de los datos. ¿A qué distancia está la ubicación desde el inicio del segmento TCP? De hecho, es la longitud del encabezado del segmento TCP. Dado que la longitud del encabezado no es fija, el campo de compensación de datos es necesario. El desplazamiento de datos está en unidades de longitud de 32 bits, por lo que la longitud máxima del encabezado TCP es 60 (15*4) bytes.

Bits de control:

URG: este indicador indica que el campo del puntero de emergencia del paquete TCP es válido. Se utiliza para garantizar que la conexión TCP no se interrumpa e insta al medio. dispositivo de capa para procesar los datos lo antes posible;

ACK: este indicador indica que el campo de respuesta es válido, lo que significa que el número de respuesta TCP mencionado anteriormente se incluirá en el paquete TCP; valores: 0 y 1. Cuando es 1, indica una respuesta El campo es válido, en caso contrario es 0

PSH: Este indicador indica la operación Push. La llamada operación Push significa que después de que el paquete de datos llega al extremo receptor, se transmite inmediatamente al programa de aplicación en lugar de ponerse en cola en el búfer

RST: este indicador indica una solicitud de restablecimiento de la conexión; Se utiliza para restablecer conexiones que han generado errores, y también se utiliza para rechazar paquetes de datos erróneos e ilegales.

SYN: Representa el número de secuencia de sincronización, utilizado para establecer conexiones; El indicador SYN se usa junto con el indicador ACK. Cuando se solicita una conexión, SYN = 1, ACK = 0 cuando se responde la conexión, los paquetes SYN = 1, ACK = 1 se usan a menudo para escanear puertos; .

El escáner envía un paquete de datos solo con SYN. ​​Si el otro host responde con un paquete de datos, significa que este puerto existe en este host, ya que este método de escaneo es solo el primer protocolo de enlace de tres vías de TCP; , este escaneo El éxito indica que la máquina escaneada no es muy segura. Un host seguro forzará una conexión a realizar estrictamente el protocolo de enlace TCP de tres vías

FIN: indica que el remitente ha llegado al final de; los datos, es decir, una vez completada la transmisión de datos entre ambas partes, no se pueden transmitir datos. Después de enviar el paquete de datos TCP con el indicador FIN, la conexión se desconectará. Los paquetes con esta bandera también se utilizan a menudo para escanear puertos.

Ventana: un mecanismo muy importante en TCP, que representa 2 bytes, que indica la cantidad de bytes que el remitente del segmento de mensaje espera recibir. El rango de números de secuencia aceptable es desde el número de confirmación del receptor hasta el. número de confirmación más los datos entre tamaños de ventana. Habrá ejemplos para explicar más adelante.

Suma de verificación: la suma de verificación incluye el pseudo encabezado, el encabezado TCP y los datos. La suma de verificación es obligatoria para TCP y la calcula el remitente y la verifica el receptor.

Puntero de emergencia: cuando el El indicador URG es 1, el puntero de emergencia es válido, lo que indica que los datos deben procesarse primero. El puntero de emergencia señala el número de secuencia del último byte de datos urgentes en el segmento TCP, para que el receptor pueda saber cuánto duran los datos de emergencia.

Opciones: La opción más utilizada es el Tamaño máximo de segmento (MSS), que notifica a la otra parte la longitud máxima del segmento TCP que la máquina puede recibir. La opción MSS sólo se envía en solicitudes para establecer una conexión.

Ponlo en la trama Ethernet para ver la posición de TCP.

El paquete TCP está en la carga útil del paquete IP. La información de su encabezado requiere al menos 20 bytes, por lo que la carga útil máxima de un paquete TCP es 1480 - 20 = 1460 bytes. Dado que los protocolos IP y TCP suelen tener información de encabezado adicional, la carga útil de TCP es en realidad de unos 1400 bytes.

Por lo tanto, un mensaje de 1500 bytes requiere dos paquetes TCP. Una mejora importante del protocolo HTTP/2 es comprimir la información del encabezado del protocolo HTTP para que una solicitud HTTP pueda colocarse en un paquete TCP en lugar de dividirse en varios paquetes, aumentando así la velocidad.

La carga útil de un paquete de datos Ethernet es de 1500 bytes y la carga útil de un paquete de datos TCP es de aproximadamente 1400 bytes.

Un paquete tiene 1400 bytes, por lo que para enviar una gran cantidad de datos a la vez, es necesario Dividir en varios paquetes. Por ejemplo, para un archivo de 10 MB, es necesario enviar más de 7100 paquetes.

Al enviar, el protocolo TCP numera cada paquete (número de secuencia, SEQ para abreviar) para que el receptor pueda restaurarlo en orden. En caso de pérdida de un paquete, también podrá saber qué paquete se perdió.

El número del primer paquete es un número aleatorio. Para facilitar la comprensión, aquí lo llamaremos paquete número 1. Suponiendo que la longitud de la carga útil de este paquete es de 100 bytes, se puede deducir que el número del siguiente paquete debería ser 101. Esto significa que cada paquete puede obtener dos números: su propio número y el número del siguiente paquete. De este modo, el destinatario sabe en qué orden deben restaurarse a sus archivos originales.

Después de recibir el paquete TCP, el sistema operativo completa el ensamblaje y la restauración. Las aplicaciones no procesan paquetes TCP directamente.

Para las aplicaciones, no hay necesidad de preocuparse por los detalles de la comunicación de datos. A menos que la línea sea anormal, siempre se reciben datos completos. Los datos requeridos por la aplicación se colocan en paquetes TCP y tienen su propio formato (como el protocolo HTTP).

TCP no proporciona ningún mecanismo para indicar el tamaño del archivo original, que está especificado por el protocolo de capa de aplicación.

Por ejemplo, el protocolo HTTP tiene una información de encabezado Longitud del contenido, que indica el tamaño del cuerpo de la información. Para el sistema operativo, significa recibir continuamente paquetes de datos TCP y ensamblarlos en orden, no más de un paquete.

El sistema operativo no procesará los datos del paquete TCP. Una vez que se ensamblan los paquetes TCP, se entregan a la aplicación. Hay un parámetro de puerto en el paquete TCP, que se utiliza para especificar la aplicación que se reenviará al puerto.

Cuando la aplicación recibe los datos sin procesar ensamblados, tomando el navegador como ejemplo, leerá correctamente segmentos de datos según el campo Longitud del contenido del protocolo HTTP. Esto también significa que una comunicación TCP puede incluir múltiples comunicaciones HTTP.

El servidor envía paquetes de datos, por supuesto, cuanto más rápido mejor, lo mejor es enviarlos todos a la vez. Sin embargo, si lo envía demasiado rápido, puede perder paquetes. Muchos factores, como el bajo ancho de banda, los enrutadores sobrecalentados y los desbordamientos del búfer, pueden provocar la pérdida de paquetes. Si la línea no es buena, cuanto más rápido envíes, más perderás.

La situación ideal es conseguir la mayor velocidad que la línea permita. Pero, ¿cómo sabemos cuál es la velocidad ideal de la línea del otro lado? La respuesta es intentarlo lentamente.

Para lograr la unidad de eficiencia y confiabilidad, el protocolo TCP diseñó un mecanismo de inicio lento. Al principio, la velocidad de envío es más lenta y luego la velocidad se ajusta de acuerdo con la pérdida de paquetes: si no hay pérdida de paquetes, la velocidad de envío se acelera; si se pierde el paquete, se reduce la velocidad de envío;

El kernel de Linux se ha configurado (TCP_INIT_CWND constante). Cuando se inicia la comunicación por primera vez, el remitente envía 10 paquetes de datos a la vez, es decir, el tamaño de la "ventana de envío" es 10. Luego deténgase y espere la confirmación del receptor antes de continuar enviando.

Por defecto, el receptor envía un mensaje de confirmación por cada dos paquetes TCP recibidos. La palabra inglesa para "confirmación" es reconocimiento, por lo que este mensaje de confirmación se denomina ACK.

El ACK contiene dos datos.

Con estos dos datos, más el último número del paquete de datos que ha enviado, el emisor adivinará la velocidad de recepción aproximada del receptor, reduciendo o aumentando así la velocidad de envío. Esto se llama "ventana de envío" y el tamaño de esta ventana es variable.

Tenga en cuenta que, dado que la comunicación TCP es bidireccional, ambas partes deben enviar ACK. Es probable que los tamaños de ventana de las dos partes sean diferentes. Y ACK son solo unos pocos campos simples, generalmente combinados con datos y enviados en un paquete de datos.

Incluso para una conexión con un gran ancho de banda y una buena línea, TCP siempre comienza con 10 paquetes y, poco a poco, intenta alcanzar la velocidad de transmisión más alta. Este es el comienzo lento de TCP.

El protocolo TCP puede garantizar la integridad de la comunicación de datos. ¿Cómo se hace esto?

Como se mencionó anteriormente, cada paquete de datos lleva el número del siguiente paquete de datos. Si no se recibe el siguiente paquete, el número ACK no cambia.

Por ejemplo, ahora he recibido el paquete nº 4, pero el paquete nº 5 no ha sido recibido. Se registrará ACK, esperando recibir el paquete número 5. Después de un tiempo, se recibe el paquete número 5 y la siguiente ronda de ACK actualizará el número. Si aún no se recibe el paquete No. 5, pero se recibe el paquete No. 6 o el paquete 7, el número en el ACK no cambiará y el paquete No. 5 siempre se mostrará. Esto da como resultado muchos ACK para contenido duplicado.

Si el remitente descubre que ha recibido tres ACK repetidos consecutivos, o que no ha recibido ningún ACK después del tiempo de espera, confirmará la pérdida del paquete, es decir, el paquete número 5 se perdió, y enviará el paquete nuevamente. A través de este mecanismo, TCP garantiza que no se perderá ningún paquete.

TCP es un protocolo de ventana deslizante, es decir, la cantidad de datos que el remitente de una conexión TCP puede enviar en un momento determinado está controlada por la ventana deslizante, y el tamaño de la ventana deslizante en realidad está controlado por dos ventanas** *Se toma la misma decisión. Una es la ventana de notificación del extremo receptor. El valor de esta ventana está en la información del encabezado del protocolo TCP y se enviará al extremo emisor junto con el paquete ACK de los datos. indica que todavía hay algo en el caché del protocolo TCP del extremo receptor. ¿Cuánto espacio queda? El extremo emisor debe asegurarse de que los datos enviados no excedan este espacio restante para evitar el desbordamiento del búfer. final para limitar el tráfico Durante el proceso de transmisión, el tamaño de la ventana de notificación está relacionado con la velocidad a la que el proceso del extremo receptor recupera los datos relacionados. La otra ventana es la ventana de congestión del remitente. Este valor lo mantiene el remitente y no está incluido en la información del encabezado del protocolo. El tamaño de la ventana deslizante es el más pequeño entre la ventana de notificación y la ventana de congestión, por lo que la ventana de congestión. También se considera la ventana utilizada por el remitente para el control de flujo. Mover el borde izquierdo de la ventana deslizante hacia la derecha se llama cierre de ventana, que ocurre cuando se confirman los datos enviados (en este momento, indica que los datos han sido recibidos por el extremo receptor y ya no será necesario retransmitirlos). y se puede borrar del caché de envío del extremo emisor), el borde derecho de la ventana deslizante se mueve hacia la derecha, lo que se llama apertura de ventana, que ocurre cuando el proceso de recepción recupera datos del caché del protocolo de recepción. A medida que el extremo emisor continúa recibiendo paquetes ACK de datos enviados, la ventana deslizante se puede cerrar y abrir continuamente de acuerdo con el número de secuencia de confirmación y el tamaño de la ventana de notificación en el paquete ACK, formando un deslizamiento hacia adelante de la ventana deslizante. Si el proceso de recepción nunca recupera datos, se producirá un fenómeno de ventana 0, es decir, los bordes izquierdo y derecho de la ventana deslizante coinciden entre sí. En este momento, el tamaño de la ventana es 0 y no se pueden almacenar más datos. enviado.

En TCP, el extremo receptor (B) informará el tamaño de una ventana al extremo emisor (A), llamada ventana anunciada.

1. Sin recibir confirmación de B, A puede enviar continuamente todos los datos de la ventana. Todos los datos que se hayan enviado deben conservarse temporalmente hasta que

reciba la confirmación, para que puedan usarse al retransmitir después del tiempo de espera.

2. El número de secuencia en la ventana de envío indica el número de secuencia que se permite enviar. Obviamente, cuanto mayor sea la ventana, el remitente puede enviar continuamente más datos antes de recibir la confirmación de la otra parte y, por lo tanto, puede lograr una mayor eficiencia de transmisión. Pero el receptor debe tener tiempo para procesar los datos recibidos.

3. La parte posterior del borde posterior de la ventana de envío indica que el mensaje ha sido enviado y se ha recibido la confirmación. Obviamente ya no es necesario conservar estos datos.

4. La parte frontal del borde frontal de la ventana de envío indica que el envío no está permitido porque el receptor no ha reservado espacio de caché para el almacenamiento temporal de esta parte de los datos.

5. Hay dos cambios en el borde posterior de la ventana de envío: estacionario (no se recibe una nueva confirmación) y avanzando (se recibe una nueva confirmación)

6. Enviar allí Hay dos tipos de cambios en el borde frontal de la ventana: sigue avanzando o puede que no se mueva (no se recibe nueva confirmación)

Si el remitente de TCP no recibe la confirmación dentro del tiempo especificado , retransmitirá el segmento de mensaje enviado. El concepto de esta retransmisión es simple, pero la selección del tiempo de retransmisión es de hecho una de las cuestiones más complejas en TCP. TCP utiliza un algoritmo adaptativo que registra el momento en que se envía un segmento de mensaje y el momento en que se recibe la confirmación de respuesta.

La diferencia entre estos dos tiempos es el tiempo de ida y vuelta RTT del segmento de mensaje. TCP conserva un tiempo de ida y vuelta promedio ponderado de RTT.

El tiempo de retransmisión del tiempo de espera RTO es ligeramente mayor que el tiempo promedio ponderado de ida y vuelta

RTT:

Ese es el tiempo de ida y vuelta, que representa el tiempo requerido para un viaje desde el remitente hasta el receptor TCP está en los datos Durante el proceso de transmisión, se muestrea RTT (es decir, se mide la diferencia de tiempo entre el paquete de datos enviado y su ACK, y el valor de RTT se actualiza en función del valor medido. El algoritmo específico es detallado en TCPIP). TCP actualiza el valor de RTO en función del valor de RTT obtenido. Es decir, el tiempo de espera de retransmisión es el intervalo de retransmisión que el remitente mide cada paquete de datos saliente si no se recibe el ACK correspondiente del paquete de datos saliente. Al mismo tiempo, el paquete de datos de la tarea se pierde y los datos se retransmitirán. Generalmente, el valor RTO es mayor que el valor RTT obtenido mediante muestreo.

Si el segmento del mensaje recibido no tiene errores, pero no sigue el número de secuencia y todavía faltan algunos datos del número de secuencia en el medio, ¿puede intentar transmitir solo los datos que faltan sin retransmitirlos? ¿Que ha llegado correctamente al receptor?

La respuesta es sí, seleccionar la confirmación es un método factible.

Si desea utilizar la opción para confirmar SACK, al establecer una conexión TCP, debe agregar la opción "Permitir SACK" a las opciones del encabezado TCP, y ambas partes deben estar de acuerdo de antemano. Si utiliza la confirmación de selección,

el uso del "campo de número de confirmación" en el encabezado original permanece sin cambios. El documento SACK no especifica cómo debe responder el remitente a un SACK. Por lo tanto, la mayoría de las implementaciones aún retransmiten todos los bloques de datos no reconocidos.

En términos generales, siempre queremos que los datos se transmitan más rápido, pero si el remitente envía los datos demasiado rápido, es posible que el receptor no tenga tiempo de recibirlos, lo que provocará la pérdida de datos. El llamado control de flujo sirve para evitar que el remitente envíe demasiado rápido y permitir que el receptor reciba a tiempo.

La capacidad del enlace en la red informática, el caché y el procesador en el nodo de conmutación, etc., son todos recursos de la red. En un determinado período de tiempo, si la demanda de un determinado recurso en la red excede la parte disponible que el recurso puede proporcionar, el rendimiento de la red se deteriorará. Esta situación se llama congestión.

Método de control de congestión:

1. Inicio lento y evitación de congestión

2. Retransmisión rápida y recuperación rápida

3. Temprano aleatorio detección

1. Al principio, tanto el cliente como el servidor están en el estado CERRADO

2. Primero, el servidor escucha activamente un determinado puerto y está en el estado ESCUCHA (por ejemplo, el servidor se inicia, Iniciar monitoreo).

3. El cliente inicia activamente una conexión SYN y luego se encuentra en el estado SYN-SENT (primer protocolo de enlace, envío SYN = 1 ACK = 0 seq = x ack = 0).

4. El servidor recibe la conexión iniciada, devuelve SYN y confirma el SYN del cliente, y luego se encuentra en el estado SYN-RCVD (segundo protocolo de enlace, enviando SYN = 1 ACK = 1 seq = y ack = x+1).

5. Después de que el cliente recibe el SYN y el ACK enviados por el servidor, envía el ACK del ACK y luego está en el estado ESTABLECIDO (el tercer protocolo de enlace, enviando SYN = 0 ACK = 1 seq = x + 1 ack = y + 1).

6. Después de recibir el ACK del cliente, el servidor está en el estado ESTABLECIDO.

(Cabe señalar que X e Y pueden ser iguales y ambos pueden ser 0, porque representan los números de secuencia de los respectivos segmentos de mensajes enviados).

Liberación de conexión TCP Salude cuatro veces

1. Actualmente, tanto A como B están en el estado ESTABLECIDO.

El proceso de aplicación 2.A primero envía un segmento de mensaje de liberación de conexión a su TCP, deja de enviar datos y cierra activamente la conexión TCP.

3. Después de que B recibe el segmento del mensaje de liberación de conexión, envía una confirmación y luego B ingresa al estado CLOSE-WAIT (espera cerrada). El proceso del servidor TCP debe notificar al proceso de aplicación de alto nivel en este momento, por lo que se libera la conexión de A a B. En este momento, la conexión TCP está en un estado semicerrado, es decir, A no tiene datos para enviar. .

La conexión en el sentido de B a A no está cerrada, y este estado puede durar algún tiempo.

4. Después de que A recibe la confirmación de B, ingresa al estado FIN-WAIT-2 (espera de terminación 2) y espera el mensaje de liberación de conexión enviado por B.

5. Si B no tiene datos para enviar a A, B envía una señal de liberación de conexión. En este momento, B ingresa al estado LAST-ACK (último reconocimiento) y espera la confirmación de A.

6. Después de que A recibe el mensaje de liberación de conexión de B, debe enviar una confirmación y luego ingresar al estado TIME-WAIT (tiempo de espera). Tenga en cuenta que la conexión TCP aún no se ha liberado. El tiempo 2MSL establecido por el temporizador de espera (temporizador TIME-WAIT) debe pasar antes de que A entre en el estado CERRADO.

7. Después de que B recibe el mensaje de confirmación de A, ingresa al estado CERRADO.

Tome la solicitud de Baidu como ejemplo y observe el proceso de establecimiento de la conexión TCP de los datos reales del protocolo de enlace de tres vías.

Veamos la onda de cuatro vías nuevamente. Cuando TCP se desconecta, habrá cuatro procesos de agitación. La bandera es FIN. Encontramos la posición correspondiente en la lista de paquetes. En teoría, deberíamos encontrar 4 paquetes de datos, pero lo intenté varias veces y en realidad solo se capturaron 3 datos. . Después de verificar la información relevante, se dijo que el servidor fusionó dos paquetes enviados consecutivamente durante el proceso de envío de regreso al cliente. Por lo tanto, la siguiente explicación se basará en las tres olas posteriores a la fusión. Indique si hay algún error.

En el primer paso, cuando el programa de aplicación del host A notifica a TCP que los datos han sido enviados, TCP envía un segmento de mensaje con una marca adicional de FIN al host B (FIN significa terminar en inglés) .

En el segundo paso, después de recibir el segmento de mensaje FIN, el host B no responde inmediatamente al host A con el segmento de mensaje FIN. En lugar de eso, primero envía un número de secuencia de confirmación ACK al host A y se notifica a sí mismo. en consecuencia: la otra parte solicita cerrar la conexión (el propósito de enviar ACK primero es evitar que la otra parte retransmita el segmento FIN durante este período).

En el tercer paso, el programa de aplicación del host B le dice a TCP: Quiero cerrar completamente la conexión y TCP envía un segmento FIN al host A.

En el cuarto paso, después de recibir el segmento FIN, el host A envía un ACK al host B para indicar que la conexión se ha liberado por completo.

Esto se debe a que cuando el servidor está en estado LISTEN, después de recibir el mensaje SYN para establecer una solicitud de conexión, coloca ACK y SYN en un mensaje y lo envía al cliente.

Al cerrar la conexión, al recibir el mensaje FIN de la otra parte, solo significa que la otra parte ya no envía datos pero aún puede recibir datos. Es posible que no se hayan enviado todos los datos a la otra parte, por lo que uno puede cerrar inmediatamente o enviar algunos. Después de que los datos se envían a la otra parte, se envía un mensaje FIN a la otra parte para expresar su acuerdo para cerrar la conexión ahora. Por lo tanto, el propio ACK y FIN generalmente se envían por separado.

Hay dos razones:

Primero, para garantizar que la conexión full-duplex del protocolo TCP pueda cerrarse de manera confiable

En segundo lugar, para garantizar que la Los segmentos de datos repetidos de esta conexión se eliminan de la red. Desaparecen

Hablemos primero del primer punto. Si el Cliente está CERRADO directamente, entonces debido a la falta de confiabilidad del protocolo IP u otras razones de la red, el Servidor. no recibe el ACK respondido por última vez por el Cliente. Luego, el Servidor continuará enviando FIN después del tiempo de espera. En este momento, debido a que el Cliente ha sido CERRADO, no se puede encontrar la conexión correspondiente al FIN reenviado. Finalmente, el Servidor recibirá RST en lugar de ACK, y el Servidor pensará. es un error de conexión. Informe los problemas a la alta dirección. Aunque tal situación no provocará la pérdida de datos, hará que el protocolo TCP no cumpla con los requisitos para conexiones confiables. Por lo tanto, el Cliente no ingresa CERRADO directamente, pero mantiene TIME_WAIT Cuando recibe FIN nuevamente, puede garantizar que la otra parte reciba ACK y finalmente cierre la conexión correctamente.

Hablemos del segundo punto. Si el Cliente CIERRE directamente y luego inicia una nueva conexión al Servidor, no podemos garantizar que el número de puerto de esta nueva conexión sea diferente del que acaba de cerrar. En otras palabras, es posible que los números de puerto de la nueva conexión y de la antigua conexión sean los mismos. En términos generales, no ocurrirá ningún problema, pero todavía hay situaciones especiales: suponiendo que el número de puerto de la nueva conexión y la antigua conexión que se cerró son los mismos, si algunos datos de la conexión anterior todavía están atascados en la red, estos datos retrasados ​​se están estableciendo. Llegan al servidor solo después de la nueva conexión. Dado que los números de puerto de la nueva conexión y de la conexión anterior son los mismos, y debido a que el protocolo TCP juzga diferentes conexiones según el par de sockets, el protocolo TCP. Considera que los datos retrasados ​​​​pertenecen a la nueva conexión, por lo que se confunde con el paquete de datos de la nueva conexión real. Por lo tanto, la conexión TCP debe esperar 2 veces MSL en el estado TIME_WAIT, lo que garantiza que todos los datos de esta conexión desaparezcan de la red.

Velocidad del hardware

Carga de red y servidor

Tamaño de paquete de solicitud y respuesta

Distancia entre cliente y servidor

Complejidad técnica del protocolo TCP

Protocolo de enlace de establecimiento de conexión TCP

Control de congestión de inicio lento de TCP

Algoritmo de Nagle para agregación de datos;

Algoritmo de reconocimiento retrasado de TCP para reconocimiento combinado;

retraso TIME_WAIT y agotamiento del puerto.

Se acabó la introducción, ¿eso es todo?

Sí, eso es todo.

Suplemento:

La mayor parte del contenido está organizado para Internet para facilitar su propio estudio y revisión. Artículo de referencia:

Introducción al protocolo TCP

Protocolo TCP Explicación gráfica detallada

¿Qué es el protocolo TCP?

Análisis de captura de paquetes de Wireshark: protocolo TCP/IP

Apretón de manos de tres vías y onda de cuatro vías del protocolo TCP

Explicación detallada del protocolo TCP

Investigación sobre ancho de banda y retardo de TCP (1)