@
¿Cuenta pública superior/estrella????, ¡los artículos hardcore se entregarán lo antes posible!
Enlace | https://juejin.im/post/6844903490595061767
1. Modelo TCP/IP
El modelo de protocolo TCP/IP (Transmission Control Protocol/Internet Protocol) incluye una serie de protocolos de red que forman la base de Internet y es el protocolo central de Internet.
El modelo de referencia basado en TCP/IP divide el protocolo en cuatro capas, que son capa de enlace, capa de red, capa de transporte y capa de aplicación. La siguiente figura muestra el contraste entre las capas del modelo TCP/IP y el modelo OSI.
La familia de protocolos TCP/IP se empaqueta capa por capa de arriba a abajo. La capa superior es la capa de aplicación, que incluye http, ftp y otros protocolos familiares. La segunda capa es la capa de transporte, y en este nivel se encuentran los famosos protocolos TCP y UDP. La tercera capa es la capa de red, donde el protocolo IP es responsable de agregar direcciones IP y otros datos a los datos para determinar el destino de la transmisión. La cuarta capa es la capa de enlace de datos.Esta capa agrega un encabezado de protocolo Ethernet a los datos que se transmitirán y realiza la codificación CRC para prepararse para la transmisión de datos final.
La figura anterior muestra claramente la función de cada capa en el protocolo TCP/IP, y el proceso de comunicación del protocolo TCP/IP en realidad corresponde al proceso de apilamiento y extracción de datos. En el proceso de apilamiento, el remitente de datos encapsula continuamente el encabezado y el final en cada capa y agrega información de transmisión para garantizar que se pueda transmitir al destino. En el proceso de apilamiento, el receptor de datos elimina continuamente el encabezado y el final de cada capa para obtener los datos transmitidos finales.
La figura anterior utiliza el protocolo HTTP como ejemplo para ilustrarlo en detalle.
En segundo lugar, la capa de enlace de datos
La capa física es responsable del intercambio entre flujos de bits de 0 y 1, el nivel de voltaje de los dispositivos físicos y el parpadeo de las luces. La capa de enlace de datos se encarga de dividir la secuencia de 0 y 1 en tramas de datos para su transmisión de un nodo a otro nodo adyacente, estos nodos se identifican de manera única por MAC (MAC, dirección física, un host tendrá una dirección MAC).
Encapsulación en un marco: agregue un encabezado y una cola al datagrama de la capa de red y encapsúlelo en un marco, y el encabezado del marco incluye la dirección MAC de origen y la dirección MAC de destino.
Transmisión transparente: relleno de cero bits, caracteres de escape.
Transmisión confiable: rara vez se usa en un enlace con una tasa de error muy baja, pero el enlace inalámbrico WLAN garantizará una transmisión confiable.
Detección de errores (CRC): el receptor detecta errores y descarta la trama si se encuentra un error.
3. Capa de red
1. Protocolo IP
El protocolo IP es el núcleo del protocolo TCP/IP. Todos los datos TCP, UDP, IMCP e IGMP se transmiten en el formato de datos IP. Cabe señalar que IP no es un protocolo confiable, lo que significa que el protocolo IP no proporciona un mecanismo de procesamiento después de que los datos no se comunican, lo que se considera que es algo que debe hacer el protocolo de capa superior: TCP o UDP.
1.1 dirección IP
En la capa de enlace de datos, generalmente identificamos diferentes nodos por dirección MAC, y en la capa IP, también tenemos una identificación de dirección similar, que es la dirección IP.
La dirección IP de 32 bits se divide en bits de red y bits de dirección. Esto puede reducir la cantidad de registros de la tabla de enrutamiento en el enrutador. Con la dirección de red, puede limitar los terminales con la misma dirección de red para que estén en el mismo rango. Luego, la tabla de enrutamiento solo necesita mantener una dirección de esta dirección de red, se pueden encontrar los terminales correspondientes.
Dirección IP de clase A: 0.0.0.0~127.0.0.0
Dirección IP de clase B: 128.0.0.1~191.255.0.0
Dirección IP de clase C: 192.168.0.0~239.255.255.0
1.2 Encabezado del protocolo IP
Aquí solo introducimos: el campo TTL de ocho bits. Este campo especifica cuántas rutas pasa el paquete antes de ser descartado. Cada vez que un paquete de datos IP pasa a través de un enrutador, el valor TTL del paquete de datos se reducirá en 1. Cuando el TTL del paquete de datos llegue a cero, se descartará automáticamente.
El valor máximo de este campo es 255, es decir, un paquete de protocolo será descartado después de pasar 255 veces por el router, dependiendo del sistema este número es diferente, normalmente 32 o 64.
2. Protocolos ARP y RARP
ARP es un protocolo para obtener direcciones MAC basadas en direcciones IP.
El protocolo ARP (Resolución de direcciones) es un protocolo de resolución. Originalmente, el host no sabe a qué interfaz del host corresponde esta IP. Cuando el host quiere enviar un paquete IP, primero verificará su propio caché ARP (es decir, , una caché de tabla de correspondencia de direcciones IP-MAC).
Si el par de valores IP-MAC consultado no existe, el host enviará un paquete de difusión del protocolo ARP a la red, que contiene la dirección IP que se consultará, y todos los hosts que reciban directamente el paquete de difusión consultarán su propia dirección IP. si un determinado host que recibe el paquete de transmisión descubre que cumple con las condiciones, preparará un paquete ARP que contiene su propia dirección MAC y lo enviará al host que envió la transmisión ARP.
Después de que el host de transmisión reciba el paquete ARP, actualizará su propio caché ARP (es decir, donde se almacena la tabla de correspondencia IP-MAC). El host que envía la transmisión utilizará los nuevos datos de caché ARP para preparar la capa de enlace de datos para enviar paquetes de datos.
El trabajo del protocolo RARP es opuesto a este y no se describirá en detalle.
3. Protocolo ICMP
El protocolo IP no es un protocolo confiable y no garantiza la entrega de datos, por lo que, naturalmente, el trabajo de garantizar la entrega de datos debe ser completado por otros módulos. Uno de los módulos importantes es el protocolo ICMP (mensaje de control de Internet). ICMP no es un protocolo de alto nivel, sino un protocolo de capa IP.
Ocurrió un error al transmitir un paquete IP. Por ejemplo, el host es inalcanzable, la ruta es inalcanzable, etc., el protocolo ICMP empaquetará la información del error y la enviará de regreso al host. Déle al host la oportunidad de manejar los errores, por lo que es posible lograr la seguridad con protocolos creados por encima de la capa IP.
Cuatro, ping
Ping es posiblemente la aplicación más famosa de ICMP, que forma parte del protocolo TCP/IP. Use el comando "ping" para verificar si la red está conectada, lo que puede ayudarnos a analizar y determinar fallas en la red.
Por ejemplo: cuando no se puede acceder a uno de nuestros sitios web. Por lo general, haga ping a este sitio web. ping mostrará información útil. La información general es la siguiente:
La palabra ping proviene del posicionamiento del sonar, y lo que hace este programa es usar paquetes de protocolo ICMP para detectar si se puede acceder a otro host. El principio es usar ICMP con código de tipo 0 para enviar una solicitud, y el host que recibe la solicitud responde con ICMP con código de tipo 8.
5. Trazado de ruta
Traceroute es una herramienta importante para detectar la ruta entre el host y el host de destino, y también es la herramienta más conveniente.
El principio de Traceroute es muy, muy interesante.Después de recibir la IP del host de destino, primero envía un paquete de datos UDP con TTL=1 al host de destino, y después de que el primer enrutador que pasa recibe este paquete de datos, envía automáticamente el El TTL se reduce en 1, y después de que el TTL se convierte en 0, el enrutador descarta el paquete y, al mismo tiempo, genera un datagrama ICMP que indica que el host no puede acceder al host. Después de que el host recibe este datagrama, envía un datagrama UDP con TTL=2 al host de destino y luego estimula al segundo enrutador para que envíe un datagrama ICMP al host. Y así sucesivamente hasta llegar al host de destino. De esta forma, traceroute obtiene todas las direcciones IP del enrutador.
6.TCP/UDP
Ambos TCP/UDP son protocolos de capa de transporte, pero tienen diferentes características y diferentes escenarios de aplicación, a continuación se presenta un análisis comparativo en forma de gráfico.
orientado al mensaje
El método de transmisión orientado a mensajes es que la capa de aplicación envía el mensaje a UDP y UDP lo envía tal cual, es decir, envía un mensaje a la vez. Por lo tanto, la aplicación debe elegir el tamaño adecuado del mensaje. Si el paquete es demasiado largo, la capa IP debe fragmentarse, lo que reduce la eficiencia. Si es demasiado corto, será que la IP es demasiado pequeña.
orientado a la corriente
Para flujos de bytes, aunque la interacción entre el programa de aplicación y TCP es un bloque de datos (de diferentes tamaños) a la vez, TCP considera el programa de aplicación como una serie de flujos de bytes no estructurados. TCP tiene un búfer.Cuando el bloque de datos transmitido por el programa de aplicación es demasiado largo, TCP puede dividirlo en partes más cortas y luego transmitirlo.
Con respecto al control de congestión y control de flujo, es el enfoque de TCP, que se explicará más adelante.
Algunas aplicaciones de los protocolos TCP y UDP
¿Cuándo se debe usar TCP?
Cuando existen requisitos para la calidad de la comunicación de red, por ejemplo: todos los datos deben transmitirse a la otra parte con precisión, lo que a menudo se usa en algunas aplicaciones confiables, como HTTP, HTTPS, FTP y otros protocolos de transferencia de archivos, POP, SMTP y otro acuerdo de transmisión de correo.
¿Cuándo se debe usar UDP?
Cuando la calidad de la comunicación de la red no es alta y se requiere que la velocidad de la comunicación de la red sea lo más rápida posible, se puede usar UDP.
7. DNS
DNS (Sistema de nombres de dominio, Sistema de nombres de dominio), una base de datos distribuida en Internet que asigna nombres de dominio y direcciones IP entre sí, permite a los usuarios acceder a Internet de manera más conveniente, sin tener que recordar la cadena de números de IP que se puede leer directamente por la máquina El proceso de obtener finalmente la dirección IP correspondiente al nombre de host a través del nombre de host se denomina resolución de nombres de dominio (o resolución de nombres de host). El protocolo DNS se ejecuta sobre el protocolo UDP, utilizando el número de puerto 53.
Ocho, establecimiento y terminación de la conexión TCP
1. Apretón de manos de tres vías
TCP está orientado a la conexión, sin importar qué parte envíe datos a la otra parte, primero debe establecer una conexión entre las dos partes. En el protocolo TCP/IP, el protocolo TCP proporciona un servicio de conexión confiable y la conexión se inicializa a través de un protocolo de enlace de tres vías. El propósito del protocolo de enlace de tres vías es sincronizar los números de secuencia y los números de confirmación de ambas partes e intercambiar información sobre el tamaño de la ventana de TCP.
El primer apretón de manos : se establece la conexión. El cliente envía un segmento de solicitud de conexión, establece el bit SYN en 1 y el número de secuencia en x, luego, el cliente ingresa al estado SYN_SEND y espera la confirmación del servidor;
El segundo apretón de manos : el servidor recibe el segmento SYN. El servidor debe confirmar el segmento del mensaje SYN después de recibir el segmento del mensaje SYN del cliente y establecer el Número de reconocimiento en x+1 (Número de secuencia+1); al mismo tiempo, debe enviar el mensaje de solicitud SYN por sí mismo, y establezca el bit SYN en 1, el número de secuencia es y; el servidor coloca toda la información anterior en un segmento de mensaje (es decir, el segmento de mensaje SYN+ACK) y lo envía al cliente junto, y el servidor ingresa el Estado SYN_RECV en este momento;
El tercer protocolo de enlace : el cliente recibe el segmento SYN+ACK del servidor. Luego establezca el Número de reconocimiento en y+1 y envíe un segmento de mensaje ACK al servidor.Después de enviar el segmento de mensaje, tanto el cliente como el servidor ingresan al estado ESTABLECIDO y completan el protocolo de enlace de tres vías TCP.
¿Por qué el apretón de manos de tres vías?
Para evitar que el segmento de solicitud de conexión no válida se transmita repentinamente al servidor, se genera un error.
Ejemplo específico: "El segmento de solicitud de conexión inválida" se genera en tal situación: el primer segmento de solicitud de conexión enviado por el cliente no se pierde, sino que permanece en un nodo de red determinado durante mucho tiempo, por lo que se retrasa hasta cierto tiempo después de que se libera la conexión para llegar al servidor. Resulta que este es un segmento que ya ha expirado. Sin embargo, después de recibir el segmento de solicitud de conexión no válida, el servidor lo confundió con una nueva solicitud de conexión enviada nuevamente por el cliente.
Luego, se envía un segmento de mensaje de confirmación al cliente, aceptando establecer una conexión. Suponiendo que no se utiliza el "apretón de manos de tres vías", siempre que el servidor envíe una confirmación, se establece una nueva conexión. Dado que el cliente no ha emitido una solicitud para establecer una conexión, ignorará la confirmación del servidor y no enviará datos al servidor. Pero el servidor cree que se ha establecido la nueva conexión de transporte y ha estado esperando que el cliente envíe datos. De esta forma, se desperdician muchos recursos del servidor. El método de "apretón de manos de tres vías" puede evitar que suceda el fenómeno anterior. Por ejemplo, en la situación de ahora, el cliente no enviará una confirmación a la confirmación del servidor. Dado que el servidor no recibe la confirmación, sabe que el cliente no solicitó establecer una conexión. "
2. Saluda cuatro veces
Cuando el cliente y el servidor establecen una conexión TCP a través de un protocolo de enlace de tres vías, cuando se completa la transmisión de datos, la conexión TCP debe desconectarse. Para la desconexión de TCP, hay unas misteriosas "cuatro rupturas".
La primera ruptura : host 1 (puede ser el cliente o el servidor), establezca el número de secuencia y envíe un segmento FIN al host 2; en este momento, el host 1 ingresa al estado FIN_WAIT_1; esto significa que el host 1 no tiene datos para solicitar Enviado al host 2;
La segunda ruptura : el host 2 recibe el segmento de mensaje FIN enviado por el host 1 y devuelve un segmento de mensaje ACK al host 1, y el número de reconocimiento es el número de secuencia más 1; el host 1 ingresa al estado FIN_WAIT_2; el host 2 le dice al host 1: "I" Estoy de acuerdo con su solicitud de cierre;
la tercera ruptura : el host 2 envía un segmento FIN al host 1, solicitando cerrar la conexión, y el host 2 ingresa al estado LAST_ACK;
La cuarta ruptura : el host 1 recibe el segmento FIN enviado por el host 2, envía un segmento ACK al host 2 y luego el host 1 ingresa al estado TIME_WAIT; después de que el host 2 recibe el segmento ACK del host 1, cierra la conexión; en este tiempo, si el host 1 aún no recibe una respuesta después de esperar 2MSL, prueba que el servidor se ha cerrado normalmente. Bueno, el host 1 también puede cerrar la conexión.
¿Por qué romper cuatro veces?
El protocolo TCP es un protocolo de comunicación de la capa de transporte basado en flujo de bytes, confiable y orientado a la conexión. TCP está en modo dúplex completo, lo que significa que cuando el host 1 envía un segmento FIN, solo significa que el host 1 no tiene datos para enviar, y el host 1 le dice al host 2 que se han enviado todos sus datos; sin embargo, en este momento , el host 1 aún puede aceptar datos del host 2; cuando el host 2 devuelve el segmento ACK, significa que ya sabe que el host 1 no tiene datos para enviar, pero el host 2 aún puede enviar datos al host 1; cuando el host 2 también Cuando se envía el segmento FIN, significa que el host 2 no tiene datos para enviar, y le dirá al host 1 que no tengo datos para enviar, y luego ambas partes interrumpirán felizmente la conexión TCP.
¿Por qué esperar a 2MSL?
MSL: Maximum Segment Lifetime, que es el tiempo máximo que cualquier segmento puede estar en la red antes de ser descartado. Hay dos razones:
Asegúrese de que la conexión full-duplex del protocolo TCP se pueda cerrar de manera confiable
Asegúrese de que los segmentos de datos duplicados para esta conexión desaparezcan de la red
El primer punto: si el host 1 está directamente CERRADO, entonces debido a la falta de confiabilidad del protocolo IP u otras razones de la red, el host 2 no recibió el último ACK del host 1. Luego, el host 2 continuará enviando el FIN después del tiempo de espera. En este momento, debido a que el host 1 está CERRADO, no se puede encontrar la conexión correspondiente al reenvío de FIN. Por lo tanto, el host 1 no ingresa directamente a CLOSED, sino que mantiene TIME_WAIT, al recibir FIN nuevamente, puede asegurarse de que la otra parte reciba ACK, y finalmente cierra la conexión correctamente.
El segundo punto: si el host 1 está directamente CERRADO y luego inicia una nueva conexión con el host 2, no podemos garantizar que el número de puerto de esta nueva conexión sea diferente al de la conexión recién cerrada. Es decir, es posible que los números de puerto de la nueva conexión y la antigua conexión sean los mismos. En términos generales, no habrá problemas, pero todavía hay casos especiales: suponiendo que el número de puerto de la nueva conexión sea el mismo que el de la antigua conexión que se cerró, si algunos datos de la conexión anterior todavía están atascados la red, estos datos retrasados se establecen Después de que la nueva conexión llega al host 2, dado que los números de puerto de la nueva conexión y la conexión anterior son los mismos, el protocolo TCP piensa que los datos retrasados pertenecen a la nueva conexión, por lo que se confunde con el paquete de datos real de la nueva conexión. Por lo tanto, la conexión TCP tiene que esperar 2 veces el MSL en el estado TIME_WAIT, lo que puede garantizar que todos los datos de esta conexión desaparezcan de la red.
Nueve, control de flujo TCP
Si el remitente envía los datos demasiado rápido, es posible que el receptor no los reciba a tiempo, lo que provocará la pérdida de datos. El llamado control de flujo es hacer que la velocidad de envío del remitente no sea demasiado rápida, de modo que el receptor tenga tiempo para recibir.
El control de flujo del remitente se puede implementar fácilmente en la conexión TCP utilizando el mecanismo de ventana deslizante .
Deja que A envíe datos a B. Cuando se establece la conexión, B le dice a A: "Mi ventana de recepción es rwnd = 400" (aquí rwnd significa ventana del receptor). Por lo tanto, la ventana de envío del emisor no puede exceder el valor de la ventana de recepción dada por el receptor. Tenga en cuenta que la unidad de ventana de TCP son bytes, no segmentos. Suponga que cada segmento tiene una longitud de 100 bytes y que el valor inicial del número de secuencia del segmento de datos se establece en 1. ACK en mayúsculas indica el bit de confirmación ACK en el encabezado, y ACK en minúsculas indica el valor ACK del campo de confirmación.
Se puede ver en la figura que B realiza el control de flujo tres veces. Reduzca la ventana a rwnd = 300 por primera vez, reduzca a rwnd = 100 por segunda vez y finalmente redúzcala a rwnd = 0, es decir, el remitente no puede enviar datos. Este estado que hace que el remitente suspenda el envío continuará hasta que el host B vuelva a emitir un nuevo valor de ventana. Los tres segmentos de mensaje enviados por B a A establecen ACK = 1, y el campo de número de confirmación tiene sentido solo cuando ACK = 1.
TCP tiene un temporizador de persistencia (temporizador de persistencia) para cada conexión. Siempre que un lado de la conexión TCP reciba una notificación de ventana cero del otro lado, se inicia el temporizador de duración. Si el tiempo establecido por el temporizador de persistencia expira, se envía un segmento de mensaje de detección de control de ventana cero (que lleva 1 byte de datos) y la parte que recibe el segmento de mensaje restablece el temporizador de persistencia.
Diez, control de congestión TCP
El remitente mantiene una variable de estado de la ventana de congestión cwnd (ventana de congestión). El tamaño de la ventana de congestión depende del grado de congestión de la red y cambia dinámicamente. El remitente hace que su ventana de envío sea igual a la ventana de congestión.
El principio para que el remitente controle la ventana de congestión es: mientras no haya congestión en la red, la ventana de congestión aumentará para enviar más paquetes. Pero mientras la red esté congestionada, la ventana de congestión se reduce para reducir la cantidad de paquetes inyectados en la red.
Algoritmo de inicio lento:
Cuando el host comienza a enviar datos, si se inyecta una gran cantidad de bytes de datos en la red inmediatamente, puede causar congestión en la red, porque no está claro cuál es la carga de la red. Por lo tanto, un mejor método es detectar primero, es decir, aumentar gradualmente la ventana de envío de pequeña a grande, es decir, aumentar gradualmente el valor de la ventana de congestión de pequeña a grande.
Usualmente, cuando el segmento de mensaje acaba de comenzar a enviarse, la ventana de congestión cwnd se establece primero en un valor del segmento de mensaje máximo MSS. Después de recibir un acuse de recibo para un nuevo segmento de mensaje, la ventana de congestión aumenta como máximo en un valor de MSS. El uso de este método para aumentar gradualmente la ventana de congestión cwnd del remitente puede hacer que la velocidad a la que se inyectan paquetes en la red sea más razonable.
Cada vez que pasa una ronda de transmisión, la ventana de congestión cwnd se duplica. El tiempo transcurrido en una ronda de transmisión es en realidad el tiempo de ida y vuelta RTT . Sin embargo, se enfatiza más la "ronda de transmisión": los segmentos de mensaje permitidos para ser enviados por la ventana de congestión cwnd se envían continuamente, y se ha recibido la confirmación del último byte enviado.
Además, el "lento" de inicio lento no se refiere a la tasa de crecimiento lento de cwnd, sino a configurar cwnd=1 cuando TCP comienza a enviar segmentos, de modo que el remitente solo envíe un segmento al principio (el propósito es para probar Mire la congestión de la red), y luego aumente gradualmente cwnd.
Para evitar la congestión de la red provocada por un crecimiento excesivo de la ventana de congestión cwnd, también es necesario establecer una variable de estado ssthresh de umbral de inicio lento. El umbral de inicio lento ssthresh se utiliza de la siguiente manera:
Cuando cwnd < ssthresh, se utiliza el algoritmo de inicio lento descrito anteriormente.
Cuando cwnd > ssthresh, deje de usar el algoritmo de inicio lento y use el algoritmo para evitar la congestión en su lugar.
Cuando cwnd = ssthresh, se puede usar el algoritmo de inicio lento o el algoritmo de evitación de control de congestión. evitación de congestión
evitación de congestión
Deje que la ventana de congestión cwnd aumente lentamente, es decir, cada vez que pasa un tiempo de ida y vuelta RTT, la ventana de congestión cwnd del emisor aumenta en 1 en lugar de duplicarse. De esta forma, la ventana de congestión cwnd crece lentamente según una ley lineal, que es mucho más lenta que la tasa de crecimiento de la ventana de congestión del algoritmo de inicio lento.
Independientemente de si se encuentra en la fase de inicio lento o en la fase de prevención de congestión, siempre que el remitente juzgue que la red está congestionada (la base es que no se ha recibido ningún reconocimiento), el umbral de inicio lento ssthresh debe establecerse en la mitad de el valor de la ventana del remitente cuando se produce la congestión (pero no menos de 2). Luego restablezca la ventana de congestión cwnd a 1 y ejecute el algoritmo de inicio lento.
El propósito de hacer esto es reducir rápidamente la cantidad de paquetes enviados por el host a la red, de modo que el enrutador congestionado tenga tiempo suficiente para procesar la acumulación de paquetes en la cola.
La siguiente figura ilustra el proceso de control de congestión anterior con valores específicos. La ventana de envío ahora es tan grande como la ventana de congestión.
2. Retransmisión rápida y recuperación rápida
retransmisión rápida
El algoritmo de retransmisión rápida primero requiere que el receptor envíe una confirmación repetida inmediatamente después de recibir un segmento fuera de secuencia (para que el remitente sepa que un segmento no ha llegado a la otra parte lo antes posible) en lugar de esperar hasta que el los datos se envían solos confirmar.
Después de recibir M1 y M2, la parte receptora envía la confirmación respectivamente. Ahora suponga que el receptor no recibe M3 pero luego recibe M4.
Obviamente, el receptor no puede confirmar M4, porque M4 es un segmento recibido fuera de secuencia. De acuerdo con el principio de transmisión confiable, el receptor no puede hacer nada o enviar un acuse de recibo a M2 en el momento apropiado.
Sin embargo, de acuerdo con las reglas del algoritmo de retransmisión rápida, el receptor debe enviar una confirmación repetida de M2 a tiempo, para que el remitente pueda saber que el segmento de mensaje M3 no ha llegado al receptor lo antes posible. El remitente luego envía M5 y M6. Después de recibir estos dos mensajes, el receptor también debe enviar una confirmación repetida de M2 nuevamente. De esta forma, el emisor ha recibido un total de cuatro acuses de recibo para M2 del receptor, y los últimos tres son acuses de recibo repetidos.
El algoritmo de retransmisión rápida también estipula que siempre que el remitente reciba tres acuses de recibo repetidos seguidos, debe retransmitir inmediatamente el segmento de mensaje M3 que no ha sido recibido por la otra parte, sin continuar esperando el temporizador de retransmisión establecido por M3 para expirar.
Dado que el remitente retransmite los segmentos no reconocidos lo antes posible, el rendimiento de toda la red se puede aumentar en aproximadamente un 20 % después de adoptar la retransmisión rápida.
rápida recuperación
El algoritmo de recuperación rápida también se utiliza junto con la retransmisión rápida.El proceso tiene los siguientes dos puntos principales:
Cuando el remitente recibe tres confirmaciones repetidas seguidas, ejecuta el algoritmo de "reducción de multiplicación" para reducir a la mitad el umbral de inicio lento ssthresh.
La diferencia con el inicio lento es que el algoritmo de inicio lento no se implementa ahora (es decir, la ventana de congestión cwnd no está establecida en 1 ahora), pero el valor de cwnd se establece en el valor después de que el umbral de inicio lento ssthresh se reduce a la mitad, y luego se inicia el algoritmo para evitar la congestión ("Aumento aditivo"), de modo que la ventana de congestión crece lenta y linealmente.