Lectura recomendada:
Publiqué un círculo de amigos hace unos días y descubrí que la chica con la que me había enamorado durante mucho tiempo me dio un me gusta, ¡así que di vueltas y me quedé despierta toda la noche! ¿Crees que la chica siente por mí? ¿De qué otra manera te agradaría de repente? ¿Deberíamos aprovechar la oportunidad para confesarnos?
Así que al día siguiente simulé muchas confesiones en mi corazón, e incluso practiqué la respiración repetidamente. Por la noche, marqué la voz de WeChat de la chica. Antes de que la otra persona pudiera hablar, no pude contener mis pensamientos internos, y comencé a hablar conmigo mismo, una expresión frenética ... Cinco minutos de una vez, ¡todo es tan natural!
Pero después de que terminé de hablar, no esperé la respuesta de la chica durante mucho tiempo ... Pasó un tiempo antes de que escuche la voz de la otra persona: "¡Oye! ¡Oye! Mi señal no es buena. No escuché una palabra de lo que estabas diciendo hace un momento. Estoy de compras con mi novio ... ".
Colgué el teléfono y también hice un resumen en profundidad de mi confesión fallida. ¡La razón es porque no aprendí bien TCP!
Si entiendo el TCP, al menos debo preguntar "¿Estás ahí?" Antes de la confesión. Primero, establezca una conexión confiable y asegúrese de que la conexión sea normal antes de poder comenzar la confesión.
Si entiendo TCP, entonces necesito la confirmación constante de la otra parte cuando hablo, para asegurarme de que cada palabra que diga pueda ser escuchada por la otra parte. ¡Entonces puedo confesar el éxito!
Así que todo porque no aprendí bien TCP, así que entré a la biblioteca ...
Veamos primero la definición de TCP:
TCP se denomina Protocolo de control de transmisión (Protocolo de control de transmisión), que es un protocolo de comunicación de capa de transporte confiable, orientado a la conexión y basado en flujo de bytes. TCP es un protocolo de transporte especialmente diseñado para proporcionar un flujo de bytes de un extremo a otro confiable en una red no confiable.
Conocemos cada palabra que contiene, ¡pero no es tan fácil de entender incluso si está conectada entre sí! Luego extraeremos algunas palabras clave, que son las que resalté anteriormente: orientado a conexión, confiable, basado en flujo de bytes, capa de transporte, protocolo, ¡de extremo a extremo! La comprensión de estas palabras clave también comprende el principio de implementación de TCP, así que comencemos con estas palabras clave para analizarlas.
Capa de transporte
Hablemos primero de la capa de transporte, porque podemos ver TCP desde un nivel relativamente alto. Veamos primero el modelo clásico de referencia de red de siete capas OSI:
Cuando necesitamos intercambiar datos en la red, necesitamos pasar por varias capas. Cada capa tiene implementaciones relacionadas, el TCP del que vamos a hablar hoy es una implementación de la capa de transporte. Tal vez cuando hablamos de la capa de transporte, naturalmente pensamos en TCP, pero TCP es solo una implementación de la capa de transporte. Otros protocolos de capa de transporte comunes incluyen UDP, etc.
Sé que el texto seco es demasiado abstracto para ti, así que tomaré una bolsa y echaré un vistazo para hacer estas capas más concretas. Todos los paquetes de este artículo se envían a través del cartero para solicitarlos y luego usan wireShark para capturarlos. Si no conoce estos dos softwares, puede conocerlos primero, pero no explicaré demasiado aquí. Ingresamos el nombre de dominio de www.17coding.info en cartero, y luego enviamos una solicitud, Wireshark puede capturar el paquete de datos.
¡La figura ha marcado la relación entre cada capa y el paquete de datos capturado! ¡qué! ¿No hablamos del modelo de referencia de red de 7 capas anterior? ¿Por qué solo hay 5 capas de paquetes de datos? Preste atención a referirse a los dos caracteres. El modelo de 7 capas es un modelo teórico. En las redes reales, la capa de aplicación, la capa de sesión y la capa de presentación a menudo se integran como capa de aplicación.
¿Qué es un acuerdo?
Cuando se trata de un acuerdo, ¡es un acuerdo que ambas partes cumplen! Por ejemplo, en este artículo que escribí, puedes entender cada palabra que escribí y entender lo que quiero decir. Eso es porque todos seguimos la gramática china, que en sí misma es un acuerdo. Por ejemplo, cuando escribimos código, debemos escribirlo de acuerdo con la gramática prescrita para que el compilador pueda compilarlo correctamente.
También hay muchos protocolos en las redes informáticas, como los protocolos de capa de aplicación comunes http, ftp, protocolos dns, etc. Los protocolos comunes de la capa de transporte incluyen TCP, UDP, etc. De hecho, estos protocolos son una especificación que siguen tanto el remitente como el receptor. Si seguimos sus especificaciones, también podemos convertirnos en el implementador del protocolo, como escribir nuestro propio servidor web para manejar las solicitudes de los usuarios. ¡Incluso podemos estipular un conjunto de acuerdos para que otros los usen!
Formato de encabezado TCP
¡Hablamos sobre la definición del protocolo antes, y el protocolo TCP también debe tener ciertas especificaciones! De esta manera, ambas partes en comunicación pueden reconocer los mensajes de datos del otro e intercambiar datos. Veamos primero el formato de mensaje TCP
Un mensaje TCP contiene un encabezado de datos y un cuerpo de datos ¡El encabezado tiene una longitud fija de 5 líneas y una longitud variable de 1 línea! ¡Las primeras 5 líneas de la imagen tienen una longitud fija! Cada línea de longitud fija ocupa 4 bytes (32 bits). Por lo tanto, la longitud fija del encabezado es 5 * 4 = 20 bytes.
En este punto, podemos tomar un paquete para ver y profundizar nuestra impresión. Seguimos enviando una solicitud a www.17coding.info, y luego miramos la parte TCP del paquete de datos.
A continuación, analizaremos el encabezado TCP línea por línea:
primera fila:
1. Puerto de origen: puerto del remitente
2. Puerto de destino: puerto receptor
Anteriormente dijimos que TCP es de un extremo a otro, ¡lo que se puede reflejar bien aquí! Cada paquete de datos tiene el puerto del remitente y el del receptor. Aquí cada puerto ocupa 2 bytes (16 bits).
La segunda y tercera líneas:
1. Número de secuencia: TCP está orientado al flujo de bytes. Los datos se almacenan y envían en el búfer en bloques. El número de secuencia se usa para marcar cuántos bytes de los datos completos son el primer byte de un paquete de datos.
2. Número de confirmación: Después de cada solicitud, el receptor responderá al remitente, indicándole al otro cuántos bytes ha recibido y cuántos bytes deben enviarse desde el siguiente paquete de datos. El valor aquí es generalmente igual al número de secuencia recibido + la longitud de la parte de datos del paquete recibido.
El número de serie y el número de confirmación aquí son indispensables para asegurar la confiabilidad del TCP, lo analizaremos en detalle a través de la captura de paquetes más adelante ¡El número de serie y el número de confirmación ocupan cada uno 4 bytes (32 bits)!
Cuarta línea:
1. Desplazamiento de datos: es más apropiado llamar aquí la longitud de la cabeza. Como se mencionó anteriormente, parte de la longitud del encabezado TCP es variable, por lo que es necesario identificar dónde comienza la parte de datos del paquete de datos. Este valor ocupa 4 bits.
2. Reservado: sin usar, para uso prolongado. Este valor ocupa 3 lugares.
3. Logos: Hay 9 logotipos en total, cada uno de los cuales ocupa 1 posición y 9 posiciones en total. ¡Puedes ver estas 9 banderas en la captura de pantalla de arriba!
3.1 NS: Nonce, relacionado con la notificación de congestión explícita ECN.
3.2. CWR: El indicador CWR y el siguiente indicador ECE se utilizan en el campo ECN del encabezado IP. Cuando el indicador ECE es 1, notificará a la otra parte que la ventana de congestión se ha reducido.
3.3. ECE: ECN-Echo. Si se establece este indicador, Notifique a la otra parte que la red de la otra parte a este lado está bloqueada.
3.4. URG: Urgente, se utiliza para agregar una conexión al remitente. Por ejemplo, al descargar archivos, si necesita detener la descarga a la mitad de la descarga, debe enviar una solicitud urgente para decirle a la otra parte que deje de enviar datos. Los paquetes de datos no están en cola.
3.5 ACK: Reconocimiento, marcado como reconocimiento.
3.6 PSH: Push, correspondiente a URG, utilizado para detener el receptor.
3.7 RST: Restablecer, indica que se ha producido un error grave y que es posible que sea necesario volver a crear la conexión TCP. Si abrimos un sitio web determinado y nunca lo sacamos, y actualizamos con F5, el paquete de datos anterior será rechazado.
3.8 SYN: Se utiliza para la sincronización, al crear una solicitud. ¡Traerá esta marca al dar la mano!
3.9 FIN: se utiliza cuando la comunicación finaliza y la conexión se libera. ¡Traerá esta marca al agitar!
4. Ventana: Ya sea el remitente o el receptor, hay ventanas de envío y recepción correspondientes. Antes de la comunicación, las dos partes negociarán el tamaño de la ventana. El remitente establece su propia ventana de envío de acuerdo con la ventana de recepción del receptor, y la ventana de envío también está limitada por la ventana de congestión ¡Esto se mencionará en la sección de control de congestión! Durante el proceso de envío, la ventana se ajustará de acuerdo con la capacidad de procesamiento del receptor. ¡Este valor tiene un gran efecto en la transmisión confiable y el control de flujo de TCP! Este valor ocupa 16 bits.
La quinta línea:
1. Checksum: se utiliza para verificar si el paquete de datos está completo o modificado. Este valor ocupa 16 bits.
2. Puntero urgente: el puntero utilizado para marcar los datos urgentes en este segmento, es decir, indica que los datos desde el encabezado de la parte de datos del paquete de datos hasta la posición especificada son datos urgentes, y solo comienza cuando el bit de bandera URG está establecido efecto. Este valor ocupa 16 bits.
Sexta línea:
1. Opciones: hay algunos datos importantes en las opciones. Elijamos algunos y hablemos de ellos.
1.1 MSS: El nombre completo de MSS es Tamaño máximo de segmento, la longitud máxima de datos que puede transportar cada segmento negociado por ambas partes (excluyendo el encabezado del segmento).
1.2 WS: El nombre completo de WS se llama Escala de ventana, también llamado factor de ventana. Se utiliza para ajustar el tamaño de la ventana. Anteriormente hablamos sobre el campo de tamaño de ventana, entonces, ¿para qué es el factor de ventana? El ancho de banda de la red y la configuración de hardware iniciales eran relativamente deficientes, por lo que el tamaño máximo de la ventana es de solo 16 bits reservados, es decir, el valor máximo que se puede establecer es 65535. Con el desarrollo de hardware y redes, 65535 ya no puede estar satisfecho. ¡Así que agregué una opción WS para expandir! Si se establece WS, el tamaño real de la ventana es igual al tamaño de la ventana multiplicado por el factor de la ventana.
1.3. SACK: El nombre completo de SACK es Selective ACK ¡El reconocimiento selectivo se basa en los reconocimientos acumulados (descritos más adelante)! SACK solo se puede enviar cuando se reciben paquetes fuera de secuencia. Si el receptor recibe el siguiente paquete de datos y descubre que el paquete de datos anterior se ha perdido, notificará al remitente qué segmentos faltan y necesitan ser retransmitidos.
2. Relleno: este campo sirve para hacer que el encabezado completo sea un múltiplo de 4 bytes. ¡Hay muchos usos similares en java!
Encontramos un paquete de datos y miramos sus datos de encabezado detallados:
1. La parte roja muestra que la longitud del encabezado TCP es de 32 bytes y la parte de la opción es de 12 bytes. Anteriormente dijimos que el encabezado TCP tiene una longitud fija de 20 bytes, por lo que 20 + 12 = 32.
2. El tamaño de ventana de la línea amarilla es de 259 bytes y el factor de ventana es de 256. ¡Entonces el tamaño real de la ventana es 259 * 256 = 66304!
Cómo entender la orientación a la conexión
En el ejemplo de mi confesión fallida, puedo ver que comencé a confesar antes de asegurarme de que la conexión es normal, lo que hizo que terminara de hablar pero la otra parte no lo escuchó debido a la mala señal. Si me aseguro de que la conexión es normal de antemano, ¡esto no sucederá! Dijimos anteriormente que TCP está orientado a la conexión, entonces, ¿cómo está orientado a la conexión TCP?
¿Qué explicaron los tres apretones de manos?
Sí, ¡todo empezó con un apretón de manos! Todos sabemos que TCP necesita pasar por tres apretones de manos para establecer una conexión, entonces, ¿qué explica cada apretón de manos? ¿No funcionaría si solo hubiera dos apretones de manos? Veamos primero una escena en la que se conecta una llamada:
A: Hola, ¿puedes oírlo?
B: Puedo oírlo, ¿puedes oírlo?
R: Yo también puedo oírlo.
...
Antes de la llamada formal, para garantizar la fiabilidad de la llamada, a menudo es necesario confirmar a través de las tres conversaciones anteriores. ¿Son necesarios estos tres diálogos? ¿Cuál es la necesidad de cada conversación?
A: Hola, ¿puedes oírlo? (Hágale saber a B que A puede hablar)
B: Puedo oír, ¿puede oír usted? (Hágale saber a A que B puede oír y hablar)
A: Yo también puedo oír. (Hágale saber a B que A puede oír)
...
Solo después de tres conversaciones puede confirmar que la otra parte puede escuchar su voz y que la voz de la otra parte puede ser escuchada. Esto permitirá el diálogo de seguimiento. Aquí tenemos que ofrecer la imagen clásica del apretón de manos de tres vías:
Analizamos el proceso de apretón de manos de tres vías y el estado después de cada apretón de manos de la siguiente manera:
1. El host A envía la identificación SYN = 1 (SYN significa que A solicita establecer una conexión con B, como se mencionó anteriormente cuando se habla del encabezado TCP), el número de secuencia Seq = x, el estado de A es SYN_SENT después de que se envía la primera solicitud de reconocimiento, Después de que B recibe la solicitud, el estado cambia de LISTEN a SYN_RCVD.
2. Después de recibir la solicitud de conexión, el host B envía la identificación SYN = 1, ACK = 1 (SYN significa que B solicita establecer una conexión con A, ACK significa responder a la solicitud de conexión de A), número de secuencia Seq = y, número de confirmación Ack = (x + 1), después de que A recibe la confirmación de B, el estado se convierte en ESTABLECIDO y el estado de B sigue siendo SYN_RCVD.
3. Después de que el host A lo reciba, verifique si Ack es correcto. Si es correcto, envíe la identificación ACK = 1 (que representa una respuesta a la solicitud de conexión de B), número de secuencia Seq = (x + 1), número de confirmación Ack = (y + 1) . Después de que B recibe la confirmación de A, ¡el estado de A y B se convierte en ESTABLECIDO!
Los puntos a los que debemos prestar atención aquí son:
1. ¡El SYN y ACK entre paréntesis en la solicitud de envío en la figura son los bits de bandera en el encabezado TCP mencionado anteriormente! Y Seq y Ack representan el número de serie y el número de confirmación respectivamente.
2. Después de recibir la Seq enviada por el remitente, el receptor responde con un Ack. El valor de Ack es igual a Seq + 1, lo que significa que el remitente está a punto de comenzar a enviar los datos en la posición Seq + 1.
2. Después de recibir la solicitud de conexión de A, B envía los dos bits de identificación SYN y ACK en la respuesta al mismo tiempo, y envía la solicitud para establecer la conexión y la respuesta a A en el mismo paquete. Por eso solo se necesitan tres apretones de manos. Se puede establecer la conexión.
Seguimos enviando una solicitud a www.17coding.info, el siguiente es el paquete de protocolo de enlace de tres vías:
En la columna de información, obviamente podemos ver que el encabezado del paquete de datos enviado tiene las banderas que mencionamos anteriormente, así como información de encabezado como Seq y Ack, y datos de opciones de encabezado como Win y MSS. Por lo tanto, el protocolo de enlace de tres vías no es solo establecer una conexión, ¡sino también negociar algunos parámetros!
Cuando selecciono una fila con el mouse, si el paquete de datos contiene un reconocimiento de un cierto paquete de datos (es decir, hay una marca ACK), puedo ver una pequeña marca en la columna No del paquete de datos correspondiente, como el anterior En la imagen, mi mouse selecciona el paquete de datos del tercer apretón de manos, y hay una pequeña marca delante del paquete de datos del segundo apretón de manos.
¿Por qué solo se necesitan tres para dar la mano y cuatro para saludar?
A través del protocolo de enlace de tres vías, las dos partes han establecido una conexión confiable y los datos se pueden transmitir. Cuando se completa la transferencia de datos, la conexión debe cerrarse, ¡porque la conexión también es un recurso! ¡Se necesitan cuatro ondas para cerrar la conexión!
¿Por qué se necesitan tres apretones de manos para completar un apretón de manos, pero cuatro ondas? ¿Puedo hacerlo tres veces? De hecho, ¡no tiene nada de malo! Por ejemplo, la siguiente escena de diálogo:
R: Ya terminé, ¡cuelga después de que termines!
B: Está bien, ya terminé y puedo colgar.
A: Vale, adiós.
colgar…
De esta manera, se pueden lograr tres conversaciones agitando las manos, pero en la red real, cuando envío una solicitud, el cuerpo de respuesta del servidor puede ser relativamente grande y ¡lleva mucho tiempo transmitir! Por lo tanto, cuando el cliente inicia una solicitud de desconexión, el servidor primero responde con un acuse de recibo y luego envía la solicitud de desconexión del servidor después de que se completa toda la transmisión de datos.
R: Ya terminé, ¡cuelga cuando termines!
B: Vale ...
B: ...
B: Ya terminé, puedo colgar
A: Vale, adiós,
cuelga ...
Así que en la mayoría de los casos se requieren cuatro ondas. Sin embargo, en mi práctica personal de captura de paquetes, habrá tres ondas de manos que pueden completar la desconexión.
Aquí tenemos que ofrecer de nuevo las clásicas cuatro manos agitadas:
Analizamos el proceso de cuatro ondas y el estado después de cada onda de la siguiente manera:
1. El host A envía el indicador FIN = 1 (FIN indica que A solicita cerrar la conexión) para cerrar la transmisión de datos de A a B. En este momento, el estado de A es FIN_WAIT_1.
2. El host B envía un ACK a A después de recibir la solicitud de cierre (ACK significa responder a la solicitud de conexión de cierre de A), y A ya no envía datos a B. En este momento, el estado de A es FIN_WAIT_2 y B es CLOSE_WAIT.
3. El host B envía el indicador FIN = 1 para cerrar la transmisión de datos de B a A. En este momento, el estado de A es TIME_WAIT y B es LAST_ACK.
4. El host A envía un ACK a B después de recibir la solicitud de cierre, y B ya no envía datos a A en este momento. En este momento, tanto A como B están cerrados y el estado se vuelve CERRADO.
En la figura, podemos ver que el estado TIME_WAIT de A continuará durante 2MSL y luego se cerrará. ¡El chino de MSL (Duración máxima del segmento) se puede traducir como "tiempo máximo de supervivencia del mensaje"! Es el tiempo más largo que ha existido un mensaje en la red, y el mensaje se descartará después de este tiempo. ¿Cuál es la función de TIME_WAIT para mantener 2MSL?
1. El Host A envía un ACK al Host B en la cuarta ola. Si la conexión se cierra directamente después de que se completa el envío, si B no recibe el ACK debido a razones de red, entonces B no puede cerrar la conexión. Por lo tanto, después de que A responde a la confirmación, aún debe esperar. En caso de que B no reciba la respuesta, continuará enviando la solicitud FIN.
2. Si no espera a 2MSL, el puerto del cliente puede ser reutilizado. Si usa este puerto nuevamente para establecer una conexión con el servidor, habrá interferencia entre las dos conexiones usando la misma tupla de cuatro!
Veamos el paquete ondulado enviado a www.17coding.info:
¡Tal vez no pueda ver inmediatamente los cuatro paquetes de datos ondulados cuando captura los paquetes! Eso es porque en HTTP1.1 y posteriores, las conexiones largas están habilitadas de forma predeterminada. Es decir, después de una solicitud, la conexión establecida no se cerrará inmediatamente, sino que será utilizada por otras solicitudes posteriores para reducir el consumo de recursos de cada restablecimiento de la conexión. Si desea capturar cuatro paquetes ondulados inmediatamente después de enviar la solicitud, puede configurar el encabezado Http Connection:close. ¡Así que cada vez que envíe una solicitud, podrá ver el apretón de manos completo de tres vías y cuatro manos agitadas!
¿Cómo garantiza TCP una transmisión fiable?
Para garantizar la fiabilidad de la transmisión Ya hemos mencionado la orientación a la conexión, establecer una conexión es el primer paso para garantizar la transmisión de datos. ¿Cómo asegurar una transmisión de datos confiable después de que se establezca la conexión?
Volvamos al escenario de nuestra llamada telefónica, por lo general, en el proceso de diálogo, ambas partes tienen que interactuar y responder entre sí. ¡No es que una persona siga hablando y la otra no responda! Por ejemplo, el siguiente escenario:
A: Déjame decirte, conocí a una chica en línea la semana pasada
B: ¡Oh, increíble!
A: Entonces ayer hice una cita para encontrarnos
B: 666! ¿y entonces?
A: Entonces nosotros @ # ￥% ...... &
B: Joder, no entendí lo que dijiste ahora, ¿lo dices de nuevo? ...
Dicha confirmación y respuesta aseguran que la comunicación entre las dos partes pueda ser completa y confiable. TCP también usa este mecanismo de retransmisión de respuesta y confirmación para asegurar una transmisión confiable en redes no confiables. Mientras no reciba la confirmación, creo que no se envió correctamente y la volveré a enviar.
Deja de esperar el acuerdo
El protocolo de parada de espera significa que cada vez que se envía un paquete de datos a la otra parte, debe esperar la respuesta de la otra parte y luego enviar el siguiente paquete de datos. Deje de esperar el acuerdo tendrá las siguientes situaciones:
1. Sin condición de error: A envía el paquete M1 a B, y B le dará a A una confirmación después de recibirlo. Cuando A reciba la confirmación de B, enviará el paquete M2.
2. Retransmisión de tiempo de espera: A envía el paquete M1 a B. Si el paquete se pierde durante el proceso de envío, A lo reenviará. El tiempo que A espera la retransmisión es un poco más que el tiempo de ida y vuelta (RTT) de un mensaje.
3. Pérdida de confirmación: si B se pierde al enviar la confirmación a A, A reenviará el paquete M1 a B. Dado que B ya ha procesado el paquete de datos M1, B descartará el paquete y luego retransmitirá la confirmación M1 a A.
4. La confirmación llega tarde: si A envía el paquete de datos M1 a B, B se retrasará cuando responda para confirmar. En este momento, A reenviará el paquete M1 a B, y B descarta el paquete de datos después de recibirlo, y luego retransmite la confirmación M1 a A. En este momento, A recibirá múltiples confirmaciones y A también descartará la confirmación después de recibir la confirmación tardía por segunda vez.
Como podemos ver en lo anterior, el protocolo de parada en espera siempre espera hasta que se recibe la confirmación antes de enviar el siguiente paquete de datos. Mientras no reciba su confirmación, asumo que no ha recibido el paquete de datos que le envié, ¡y lo reenviaré! Aunque esto es confiable, ¡conducirá a una menor utilización del canal!
Transmisión por tubería
La transmisión por canalización consiste en enviar varios conjuntos de paquetes de datos a la vez, y no es necesario detenerse y esperar la confirmación de la otra parte después de enviar un conjunto cada vez. Dado que siempre hay una transmisión de datos ininterrumpida en el canal, se puede obtener una tasa de utilización del canal más alta.
¿Cómo garantizar la fiabilidad de la transmisión por tuberías? El remitente debe mantener la ventana de envío. Si la ventana de envío es 5, se enviarán 5 paquetes de datos al mismo tiempo, ¡y luego esperará la confirmación! Si hay una confirmación del receptor, la ventana se deslizará y se enviará el sexto paquete.
Si se trata de una única confirmación, la eficiencia puede ser relativamente baja, por lo que hay una confirmación acumulativa. Es decir, si el remitente envía los paquetes de datos 1, 2, 3, 4, el receptor solo necesita responder a la confirmación del paquete de datos 4, lo que significa que se han recibido los 1234 paquetes de datos y se puede enviar el quinto paquete de datos. ¡Arriba! Si se envían los paquetes de datos 1, 2, 3, 4 y se pierde el tercer paquete, ¿cómo confirmarlo? TCP solo responderá al acuse de recibo del paquete 2 y confirmará selectivamente el paquete 4 (SACK mencionado en la opción de encabezado TCP), para que el remitente sepa que el paquete 4 se envió correctamente y solo necesita reenviar el paquete. 3.
Continuando con el ejemplo de captura de paquetes anterior, el receptor no confirma todos los paquetes, pero confirma de forma acumulativa varios paquetes:
Aquí podemos ver que el cliente solo confirma una vez después de que el servidor envía varios paquetes.
Control de flujo y control de congestión
Por lo anterior sabemos que al establecer una conexión confiable y un mecanismo de confirmación, ¡la confiabilidad de la conexión TCP está garantizada! Sin embargo, la capacidad de procesamiento de la computadora utilizada por todos es diferente ¿Qué pasa si envío demasiado rápido y la otra parte no puede manejarlo? ¿Cómo coordinan las partes comunicantes la frecuencia de envío y recepción de datos?
Tecnología de ventana deslizante en bytes
Al introducir el encabezado TCP, ya mencionamos la ventana deslizante e introdujimos el parámetro de control relevante Win! Hablando de ventana de recepción y ventana de envío. ¿Cómo es su relación?
Suponiendo que A necesita transmitir datos a B, B primero debe decirle a A qué tan grande es su ventana de recepción. ¡A configura su propia ventana de envío de acuerdo con la ventana de recepción de B! ¡La ventana de envío de A no puede ser mayor que la ventana de recepción de B! Antes de comenzar a transferir datos, la configuración inicial de la ventana es la siguiente:
Como se muestra en la figura anterior, ¿podemos ver que la ventana de recepción de B está configurada en 10 bytes y la ventana de envío de A no puede exceder los 10 bytes? Si comienza a transmitir datos, A encapsulará los datos en varios paquetes de datos para su transmisión, como se muestra a continuación.
Antes de recibir la confirmación de B, la ventana de A no se deslizará, lo que significa que se pueden enviar hasta 10 bytes de datos. Si B recibe los datos y confirma la respuesta a A, entonces la ventana de A se deslizará, como se muestra en la siguiente figura:
De esta forma, A puede enviar de nuevo los bytes 11 y 12. Si la capacidad de procesamiento de B se debilita, también puede notificar a A para reducir la ventana de envío. De esta manera, las capacidades de recepción y envío de ambas partes están bien coordinadas. ¡Esta es una buena realización de la transmisión confiable y el control de flujo de TCP!
El paquete de datos anterior continúa enviándose. Si el paquete de datos compuesto por 3, 4 y 5 bytes se pierde durante el proceso de envío, pero se reciben los siguientes datos, ¿se moverá la ventana de envío de A?
Si este es el caso, la ventana de envío de A no se moverá. Cuando B recibe el siguiente paquete de datos, la respuesta Ack a A se establecerá en 3, y se establecerá un SACK en la opción (descrita en la opción de encabezado TCP) para decirle a A qué parte de los datos se ha recibido y qué parte de los datos se necesita ¡Retransmitir!
Control de congestión
Con la tecnología de ventana deslizante, las capacidades de recepción y envío de ambas partes pueden coordinarse bien. Sin embargo, las condiciones de la red son muy complicadas y puede haber miles de remitentes y receptores en la misma red. Si todo el mundo necesita transmitir datos y ocupar la red, la falta de medidas de control hará que toda la red se bloquee o incluso se paralice.
Si tuviera que conducir de Shenzhen a Guangzhou, tomaría la autopista. Si yo fuera el único que condujera, ¡seguramente no tendría obstáculos! Pero la carretera no es mía, ¡todos pueden pasar! Entonces, cuando llega la festividad, todos acuden a ella, ¡y la capacidad de carga de alta velocidad no se ajustará debido a la festividad! En este momento, a menudo se necesitan medidas como el control del tráfico y la limitación de corriente para facilitar el tráfico.
1. ¡La línea verde representa una situación ideal, si el rendimiento de la autopista es 100! Cuando el número de vehículos para rebasar no supera los 100, ¡todos los vehículos pueden pasar sin problemas! Cuando deben pasar más de 100 vehículos, la cantidad de vehículos que pasan cada vez es 100 y la carga que se puede proporcionar es relativamente estable.
2. Rojo significa que si el rendimiento de la autopista es 100 sin ningún control de tráfico. Cuando el número de vehículos que deben rebasar no supere los 100, se producirá un ligero atasco. Sin embargo, a medida que aumenta el número de vehículos, se producirá una congestión grave o incluso parálisis.
3. Azul significa que bajo control de tráfico, ¡si el rendimiento de la autopista es 100! Cuando el número de vehículos que deben rebasar no supere los 100, se producirá un ligero atasco. Pero con el aumento de vehículos, el tráfico se ha mantenido alto y no habrá parálisis.
La red es como una carretera, y los paquetes de datos transmitidos son como vehículos para pasar, y TCP es más como un policía de tránsito, ¡manteniendo el orden de transmisión de datos! ¿Cómo lo hace TCP?
Inicio lento y prevención de la congestión
El remitente mantiene un cwnd (ventana de congestión, ¡tenga en cuenta que la ventana de congestión aquí no puede ser mayor que la ventana de envío mencionada anteriormente!), Y la ventana de congestión se establece en 1. Si se encuentra que el paquete no se ha perdido, ajuste la ventana de congestión a 2. Si no hay pérdida de paquetes, ajuste la ventana de congestión a 4. ¡De esta manera cada vez crece a 16 a razón de 2 veces! Luego, 17, 18, 19 se incrementan uno por uno hasta que el tamaño sea consistente con la ventana de envío. Este es el llamado inicio lento y prevención de la congestión, 16 es el umbral de inicio lento ...
¿Tienes la sensación de conseguir una pulgada?
Cengceng no voy ...
...
entré sin moverme ...
...
yo ...
Si se detecta pérdida de paquetes durante la transmisión, el tamaño de la ventana de congestión se ajustará a 1 y el nuevo umbral de inicio lento se establecerá en la mitad del tiempo en que ocurre la congestión, es decir, cuando la ventana de congestión es 24, habrá pérdida. En caso de fenómeno de paquetes, ¡el nuevo umbral de inicio lento se ajusta a 12! Si comprende la descripción del texto anterior, la siguiente figura no es difícil de entender.
Retransmisión rápida
Hablé antes sobre la confirmación acumulativa y también sobre la confirmación selectiva. ¡Esto está relacionado con la retransmisión rápida! Si el receptor encuentra la pérdida de un paquete, no esperará la confirmación acumulativa y notificará al remitente de tres confirmaciones repetidas para notificar a la otra parte que reenvíe el paquete perdido. Cuando el receptor recibe tres confirmaciones repetidas, se da cuenta de que el paquete de datos se ha perdido y lo retransmite.
Como se puede ver en la figura siguiente, cuando hay una pérdida de paquetes, el Ack del receptor es igual a 50, y SACK confirma selectivamente los bytes entre 60 y 89. En este momento, el remitente también sabe que los datos de 50 59 se pierden y se retransmiten.
Rápida recuperación
Si una vez se produce la pérdida de paquetes, la ventana de congestión se convierte en 1, lo cual es demasiado tonto. ¡Sería genial si pudiera haber un mecanismo de recuperación rápida! TCP utiliza el mecanismo de recuperación rápida. Cuando hay una pérdida de paquetes, el inicio lento no se volverá a realizar, sino que irá directamente a evitar la congestión. Es decir, se agrega y aumenta el nuevo umbral de inicio lento.
Después de leer el texto completo, volvamos a la definición de TCP, ¿puedes entenderlo de nuevo?
TCP se denomina Protocolo de control de transmisión (Protocolo de control de transmisión), que es un protocolo de comunicación de capa de transporte confiable, orientado a la conexión y basado en flujo de bytes. TCP es un protocolo de transporte especialmente diseñado para proporcionar un flujo de bytes de un extremo a otro confiable en una red no confiable.