El contenido proviene de Internet, incluido en mi Evernote, y ahora lo comparto
Todo el mundo sabe que OSI tiene siete capas (debe transmitir datos de red) y TCP / IP tiene cinco capas (debe transmitir datos de red). ¿Pero por qué? ¿Qué se ha reducido?
Puede ver el siguiente diagrama para comparar,
pero ¿qué hacen las capas? Se estima que pocas personas pueden responderla. Eche un vistazo a la imagen de abajo para ver si es lo mismo que lo que piensa.
Luego, alguien debería decir de nuevo, ¿cómo pueden entender esto las personas que no entienden las computadoras? Está bien. Miremos hacia abajo. Supongamos que usted es un hombre de negocios Lao Zhang y el otro es un hombre de negocios Lao Wang. Los dos quieren hacer un negocio, por lo que ocurrió la siguiente "transacción".
Supongo que lo leyó aquí y probablemente lo comprenda eso. De hecho, en lo que respecta a la familia de protocolos TCP / IP, está empaquetada capa por capa de arriba a abajo.
- La capa superior es la capa de aplicación, donde hay http, ftp y otros protocolos familiares.
- La segunda capa es la capa de transporte, y los conocidos protocolos TCP y UDP se encuentran en este nivel.
- La tercera capa es la capa de red, aquí está el protocolo IP, que se encarga 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, que agrega un encabezado de protocolo Ethernet a los datos que se van a transmitir y realiza la codificación CRC para preparar la transmisión de datos final.
- La quinta capa es la capa física, es decir, el equipo físico.
La figura anterior muestra claramente el papel de cada capa en el protocolo TCP / IP , y el proceso de comunicación del protocolo TCP / IP corresponde en realidad al proceso de apilamiento y estallido de datos.
- En el proceso de apilamiento, el remitente de datos encapsula continuamente el encabezado y la cola en cada capa, agregando algo de información transmitida para garantizar que se pueda transmitir al destino.
- En el proceso de desapilamiento, el receptor de datos elimina continuamente el encabezado y la cola en cada capa para obtener los datos transmitidos finales.
【Capa de enlace de datos】
La capa física es responsable del intercambio de flujos de 0 y 1 bit con el nivel de voltaje del dispositivo físico y el destello de luz. La capa de enlace de datos es responsable de dividir la secuencia de 0 y 1 en tramas de datos que se transmiten de un nodo a otro nodo adyacente.Estos nodos se identifican de forma única por MAC (MAC, dirección física, un host tendrá una dirección MAC).
- Encapsular en una trama: agregue el encabezado y el final al datagrama de la capa de red y encapsúlelo en una trama. El encabezado de la trama incluye la dirección MAC de origen y la dirección MAC de destino.
- Transmisión transparente: relleno de bits cero, caracteres de escape.
- Transmisión confiable: Rara vez se usa en un enlace con una tasa de error baja, pero la WLAN del enlace inalámbrico asegurará una transmisión confiable.
- Detección de errores (CRC): el receptor detecta un error y, si se encuentra un error, la trama se descarta.
【Capa de red】
1. Protocolo IP
** El protocolo IP es el núcleo del protocolo TCP / IP, todos los datos TCP, UDP, IMCP, IGMP se transmiten en formato de datos IP. ** Cabe señalar que IP no es un protocolo confiable. Esto significa que el protocolo IP no proporciona un mecanismo para procesar los datos después de que no se comunican. Este se considera el protocolo de capa superior: TCP o UDP.
1.1 dirección IP
En la capa de enlace de datos, generalmente usamos direcciones MAC para identificar diferentes nodos, 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 una dirección de red, puede limitar los terminales con la misma dirección de red para que estén en el mismo rango, por lo que la tabla de enrutamiento solo necesita. Al mantener una dirección para esta dirección de red, puede encontrar los terminales correspondientes.
- Dirección de clase A: 1.0.0.1-126.255.255.254
- Dirección de clase B: 128.1.0.1-191.255.255.254
- Dirección de clase C: 192.0.0.1-223.255.255.254
- Dirección de clase D: 224.0.0.1-239.255.255.255
donde: - Dirección de bucle: 127.0.0.1-127.255.255.255
- Dirección de transmisión: 255.255.255.255.255
1.2 encabezado del protocolo IP
Aquí solo presentamos: el campo TTL de ocho bits. Este campo especifica cuántas rutas atravesará 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 disminuirá en 1. Cuando el TTL del paquete de datos sea cero, se descartará automáticamente.
El valor máximo de este campo es 255, lo que significa que un paquete de protocolo se descartará cuando viaje 255 veces en el enrutador. Dependiendo del sistema, este número es diferente, generalmente 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 de cuál host corresponde esta IP. Cuando el host desea enviar un paquete IP, primero verificará su propia 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 envía un paquete de difusión del protocolo ARP a la red. Este paquete de difusión contiene la dirección IP que se va a consultar, y todos los hosts que reciben directamente el paquete de difusión consultarán su propia dirección IP. , si un host que recibe el paquete de transmisión encuentra que cumple con las condiciones, preparará un paquete ARP que contiene su propia dirección MAC y lo enviará al host que envía la transmisión ARP.
El host de transmisión actualizará su caché ARP (el lugar donde se almacena la tabla de correspondencia IP-MAC) después de recibir el paquete ARP. El host que envía la transmisión utilizará los nuevos datos de caché ARP para preparar la capa de enlace de datos para el envío de paquetes de datos.
El trabajo del protocolo RARP es el opuesto, así que no lo repetiré.
3. Protocolo ICMP
El protocolo IP no es un protocolo confiable. No garantiza que los datos serán entregados. Naturalmente, el trabajo de asegurar la entrega de datos debe ser realizado por otros módulos. Uno de los módulos importantes es el protocolo ICMP (Mensaje de control de red). ICMP no es un protocolo de alto nivel, sino un protocolo de capa IP.
Se produce un error al transmitir paquetes de datos IP. Por ejemplo, el host es inalcanzable, la ruta es inalcanzable, etc. El protocolo ICMP empaquetará la información del error y luego la enviará de regreso al host. Dale al anfitrión la oportunidad de lidiar con los errores, por lo que se dice que el protocolo construido por encima de la capa IP es posible para lograr seguridad.
【silbido】
Se puede decir que Ping es la aplicación más famosa de ICMP y forma parte del protocolo TCP / IP. Utilice el comando "ping" para verificar si la red está conectada, lo que puede ayudarnos a analizar y determinar las fallas de la red.
Por ejemplo: cuando uno de nuestros sitios web no está disponible. Por lo general, haga ping a este sitio web. Ping hará eco de alguna información útil. La información general es la siguiente:
La palabra ping se deriva del posicionamiento de la sonda, y este programa hace exactamente eso: utiliza paquetes de protocolo ICMP para detectar si se puede acceder a otro host. El principio es utilizar ICMP con un código de tipo 0 para enviar una solicitud, y el host solicitado responde con ICMP con un código de tipo 8.
【Traceroute】
Traceroute es una herramienta importante que se utiliza para detectar la situación de enrutamiento entre un host y un 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 UDP con TTL = 1 al host de destino, y después de que el primer enrutador que pasa recibe este paquete, automáticamente Después de que el TTL se reduce en 1 y 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 recibir este datagrama, el host 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. Repita de esta manera hasta que llegue al host de destino. De esta manera, traceroute obtiene todas las IP del enrutador.
【TCP / UDP】
Ambos TCP / UDP son protocolos de capa de transporte , pero los dos tienen diferentes características y diferentes escenarios de aplicación El siguiente es un análisis comparativo en forma de gráfico.
Orientado a mensajes
El método de transmisión orientado a mensajes es cuánto tiempo se entrega un mensaje a UDP por la capa de aplicación, y UDP se envía tal cual, es decir, se envía un mensaje a la vez. Por lo tanto, la aplicación debe seleccionar un mensaje del tamaño adecuado. Si el mensaje es demasiado largo, la capa de IP debe fragmentarse, lo que reduce la eficiencia. Si es demasiado corto, la IP será demasiado pequeña.
Orientado al flujo de bytes
Para los flujos de bytes, aunque la interacción entre la aplicación y TCP es un bloque de datos a la vez (con diferentes tamaños), TCP trata la aplicación como una serie de flujos de bytes no estructurados. TCP tiene un búfer, cuando el bloque de datos transmitido por la aplicación es demasiado largo, TCP puede dividirlo en bloques más cortos y transmitirlo.
Con respecto al control de congestión y control de flujo, es el foco de TCP, que se explicará más adelante.
Algunas aplicaciones de los protocolos TCP y UDP
¿Cuándo debo usar TCP?
Cuando existe un requisito para la calidad de la comunicación de red, como: todos los datos deben transmitirse de manera precisa y precisa a la otra parte. Esto se usa a menudo para algunas aplicaciones confiables, como HTTP, HTTPS, FTP y otros protocolos de transferencia de archivos. y POP, SMTP y otras transmisiones de correo.
¿Cuándo debo usar UDP?
Cuando la calidad de la comunicación de la red no es alta, se requiere que la velocidad de comunicación de la red sea lo más rápida posible, luego se puede utilizar UDP.
【DNS】
DNS (Sistema de nombres de dominio), una base de datos distribuida en Internet que asigna nombres de dominio y direcciones IP entre sí, puede facilitar a los usuarios el acceso a Internet sin tener que recordar la cadena del número de IP que la máquina puede leer directamente. . A través del nombre de host, el proceso de obtener finalmente la dirección IP correspondiente al nombre de host se denomina resolución de nombre de dominio (o resolución de nombre de host). El protocolo DNS se ejecuta sobre el protocolo UDP y usa el puerto número 53.
[Establecimiento y terminación de la conexión TCP]
Tres apretón de manos
TCP está orientado a la conexión, no importa qué parte envíe datos a la otra parte, se debe establecer una conexión entre las dos partes. En el protocolo TCP / IP, el protocolo TCP proporciona servicios de conexión fiables y la conexión se inicializa mediante un protocolo de enlace de tres vías. El propósito del protocolo de enlace de tres vías es sincronizar el número de serie y el número de confirmación de las dos partes en la conexión e intercambiar información sobre el tamaño de la ventana TCP.
El primer apretón de manos : establezca una conexión. El cliente envía un segmento de solicitud de conexión, configurando la posición SYN en 1 y el Número de secuencia ax, luego, el cliente ingresa al estado SYN_SEND y espera la confirmación del servidor;
El segundo protocolo de enlace : el servidor recibe el segmento SYN. El servidor recibe el segmento SYN del cliente y necesita confirmar el segmento SYN y establecer el número de acuse de recibo en x + 1 (número de secuencia + 1); al mismo tiempo, debe enviar el mensaje de solicitud SYN en sí, configurando la posición 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, segmento de mensaje SYN + ACK) y lo envía al cliente juntos En este momento, el servidor entra en el estado SYN_RECV; el
tercer apretón de manos : el cliente recibe el segmento SYN + ACK del servidor. A continuación, establezca el número de acuse de recibo en y + 1 y envíe un segmento ACK al servidor.Después de enviar este segmento, tanto el cliente como el servidor entran en el estado ESTABLECIDO para completar el protocolo de enlace de tres vías de TCP.
¿Por qué necesitas estrechar la mano tres veces?
Para evitar que el segmento del mensaje de solicitud de conexión fallida se transmita repentinamente al servidor, se produce un error.
Ejemplo específico: "Segmento de mensaje de solicitud de conexión fallida" se genera en tal situación: el primer segmento de mensaje de solicitud de conexión enviado por el cliente no se pierde, pero permanece en un nodo de red durante mucho tiempo, de modo que se retrasa para llegar al servidor algún tiempo después de que se libere la conexión. Originalmente, este es un segmento que ha expirado hace mucho tiempo. Sin embargo, después de que el servidor recibe este segmento de solicitud de conexión no válida, lo confunde con una nueva solicitud de conexión enviada por el cliente nuevamente.
Entonces envía un segmento de confirmación al cliente, accediendo a establecer una conexión. Suponiendo que no se utiliza el "protocolo de enlace de tres vías", siempre que el servidor envíe un acuse de recibo, se establecerá una nueva conexión. Dado que el cliente no envía una solicitud para establecer una conexión, ignora la confirmación del servidor y no envía 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 manera, muchos recursos del servidor se desperdician en vano. El uso del enfoque de "apretón de manos de tres vías" puede evitar que suceda el fenómeno anterior. Por ejemplo, en el caso de este momento, el cliente no enviará una confirmación a la confirmación del servidor. Dado que el servidor no puede recibir la confirmación, sabe que el cliente no solicitó establecer una conexión. "
Saludar cuatro veces
Una vez que 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 una misteriosa "ruptura de cuatro" aquí.
Wave por primera vez : Host 1 (puede ser un cliente o un 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 a solicitar Enviado al host 2;
segunda oleada : el host 2 recibe el segmento FIN enviado por el host 1 y devuelve un segmento ACK al host 1. El número de acuse de recibo es el número de secuencia más 1; el host 1 ingresa al estado FIN_WAIT_2; el host 2 Dígale al host 1 , "Acepto" su solicitud de apagado;
tercera ola : el host 2 envía un segmento FIN al host 1, solicitando cerrar la conexión, y el host 2 entra en el estado LAST_ACK;
cuarta ola : el host 1 recibe al host 2 El segmento FIN enviado, el segmento ACK se envía al host 2, y luego el host 1 entra en el estado TIME_WAIT; después de que el host 2 recibe el segmento ACK del host 1, cierra la conexión; en este momento, el host 1 todavía espera el 2MSL Si no se recibe respuesta, prueba que el lado del servidor se ha cerrado normalmente, eso es 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 capa de transporte confiable, orientado a la conexión y basado en flujo de bytes. ** TCP es un modo full-duplex, 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 todos sus datos han sido enviados; sin embargo, el host 1 todavía puede aceptar datos del host 2 en este momento; 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 2 también se envió el segmento FIN, esta vez significa que el host 2 no tiene datos para enviar, y le dirá al host 1 que no tengo datos para enviar, y luego los demás interrumpirán felizmente la conexión TCP.
¿Por qué esperar a 2MSL?
MSL: el tiempo de supervivencia máximo de un segmento de mensaje, que es el tiempo más largo en la red antes de que se descarte cualquier segmento de mensaje.
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 el segmento de datos repetidos de esta conexión desaparezca de la red
El primer punto : si el host 1 está CERRADO directamente, entonces el host 2 no recibió el ACK final del host 1 debido a la falta de confiabilidad del protocolo IP u otras razones de la red. Luego, el host 2 continuará enviando el FIN después del tiempo de espera.En este momento, dado que el host 1 está CERRADO, no puede encontrar la conexión correspondiente al FIN retransmitido. Por lo tanto, el host 1 no ingresa CLOSED directamente, sino que mantiene TIME_WAIT. Cuando recibe FIN nuevamente, puede asegurarse de que la otra parte reciba ACK y finalmente cierre la conexión correctamente.
El segundo punto : si el host 1 está CERRADO directamente 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 del número de puerto de la conexión recién cerrada. En otras palabras, es posible que los números de puerto de la nueva conexión y la antigua sean los mismos. En términos generales, no se producirán problemas, pero aún existen circunstancias especiales: suponiendo que el número de puerto de la nueva conexión y la antigua conexión que se ha cerrado son los mismos, si algunos datos de la conexión anterior siguen atascados en la red, estos datos retrasados se están estableciendo La nueva conexión llega al host 2. Debido a que el número de puerto de la nueva conexión y la conexión anterior son los mismos, el protocolo TCP considera que los datos retrasados pertenecen a la nueva conexión, que se confunde con los datos paquete de la nueva conexión real. Por lo tanto, la conexión TCP tiene que esperar 2 veces el MSL en el estado TIME_WAIT, para asegurarse de que todos los datos de esta conexión desaparezcan de la red.
[Control de flujo de TCP]
Si el remitente envía los datos demasiado rápido, es posible que el receptor no tenga tiempo para recibirlos, lo que provocará la pérdida de datos. El llamado control de flujo es permitir que el remitente no envíe demasiado rápido, que el receptor tenga tiempo para recibir.
El uso del mecanismo de ventana deslizante puede implementar fácilmente el control de flujo en el remitente en la conexión TCP.
Deje que A envíe datos a B. Cuando se estableció la conexión, B le dijo a A: "Mi ventana de recepción es rwnd = 400" (donde rwnd significa ventana de receptor). Por lo tanto, la ventana de envío del remitente no puede exceder el valor de la ventana de recepción dada por el receptor. Tenga en cuenta que la unidad de la ventana TCP es el byte, no el segmento de mensaje. 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 representa el bit de reconocimiento ACK en el encabezado, y ack en minúsculas representa el valor ack del campo de reconocimiento.
Puede verse en la figura que B ha realizado tres controles de flujo. La primera vez que la ventana se reduce a rwnd = 300, la segunda vez se reduce a rwnd = 100 y finalmente a rwnd = 0, es decir, el remitente no puede enviar más datos. Este estado que hace que el remitente suspenda el envío continuará hasta que el host B reenvíe un nuevo valor de ventana. Los tres segmentos enviados por B a A están todos configurados con ACK = 1, y el campo del número de acuse de recibo es significativo solo cuando ACK = 1.
TCP tiene un temporizador de persistencia para cada conexión. Siempre que una parte de la conexión TCP reciba la notificación de ventana cero de la otra parte, se inicia el temporizador continuo. Si la duración establecida por el temporizador expira, se envía un segmento de mensaje de control de ventana cero (que lleva 1 byte de datos) y la parte que recibe este segmento restablecerá el temporizador de duración.
[Control de congestión de 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 propia ventana de envío sea igual a la ventana de congestión.
El principio del remitente para controlar la ventana de congestión es: Mientras no haya congestión en la red, la ventana de congestión se incrementará un poco más para que se puedan 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 una gran cantidad de bytes de datos se inyectan en la red inmediatamente, puede causar congestión en la red, porque no está clara la situación de carga de la red. Por lo tanto, un mejor método es sondear 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.
Por lo general, cuando el segmento de mensaje recién comienza a enviarse, la ventana de congestión cwnd se establece primero en el valor del segmento de mensaje máximo MSS. Después de recibir cada confirmación de un nuevo segmento, la ventana de congestión aumenta a un valor de como máximo un MSS. El uso de este método para aumentar gradualmente la ventana de congestión cwnd del remitente puede hacer que la tasa de inyección de paquetes en la red sea más razonable.
Después de cada 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, la "ronda de transmisión" se enfatiza más: los segmentos de mensaje permitidos por la ventana de congestión cwnd se envían continuamente y se recibe la confirmación del último byte enviado.
Además, el inicio lento "lento" no significa que la tasa de crecimiento de cwnd sea lenta, pero significa que cwnd = 1 se establece primero cuando TCP comienza a enviar el segmento, de modo que el remitente solo envía un segmento al inicio (el propósito es probar Mire la congestión de la red), y luego aumente gradualmente cwnd.
Para evitar que la ventana de congestión cwnd aumente demasiado y cause congestión en la red, también es necesario establecer una variable de estado ssthresh de umbral de inicio lento. El uso del umbral de inicio lento ssthresh es el siguiente:
- Cuando cwnd <ssthresh, se utiliza el algoritmo de inicio lento anterior.
- 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 utilizar el algoritmo de inicio lento o el algoritmo para evitar el control de la congestión. Evitación de la congestión
Evitación de la congestión
Deje que la ventana de congestión cwnd aumente lentamente, es decir, aumente la ventana de congestión cwnd del remitente en 1 en lugar de duplicarla cada vez que pasa un tiempo de ida y vuelta RTT. De esta forma, la ventana de congestión cwnd crece lentamente de acuerdo con 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.
Ya sea en la fase de inicio lento o en la fase de evitación de congestión, siempre que el remitente considere que la red está congestionada (la base es que no se recibe confirmación), el umbral de inicio lento ssthresh debe establecerse en la mitad del valor de la ventana del remitente cuando ocurre 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 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 mencionado anteriormente con valores específicos. El tamaño de la ventana de envío ahora es tan grande como la ventana de congestión.
Retransmisión rápida y retransmisión rápida de 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 hay un segmento que no ha llegado a la otra parte) y no esperar hasta que envía datos antes de la confirmación de transporte.
Después de recibir M1 y M2, el receptor envía confirmaciones respectivamente. Ahora suponga que el receptor no recibió M3 pero luego recibió M4.
Obviamente, el receptor no puede confirmar M4, porque M4 es un segmento de mensaje recibido fuera de secuencia. De acuerdo con el principio de transmisión confiable, el receptor no puede hacer nada o enviar una confirmación a M2 en el momento apropiado.
Sin embargo, de acuerdo con las disposiciones del algoritmo de retransmisión rápida, el receptor debe enviar una confirmación repetida de M2 de manera oportuna, de modo que el remitente pueda saber que el segmento de mensaje M3 no ha llegado al receptor lo antes posible. El remitente luego envió M5 y M6. Después de recibir estos dos mensajes, el receptor también debe enviar una confirmación repetida a M2 nuevamente. De esta forma, el remitente ha recibido un total de cuatro acuses de recibo M2 del receptor, de los cuales los tres últimos son acuses de recibo repetidos.
El algoritmo de retransmisión rápida también estipula que mientras el remitente reciba tres acuses de recibo repetidos seguidos, debería retransmitir inmediatamente el segmento de mensaje M3 que la otra parte no ha recibido, en lugar de esperar a que expire el temporizador de retransmisión fijado por M3.
Dado que el remitente retransmite el segmento sin acuse de recibo lo antes posible, el uso de la retransmisión rápida puede aumentar el rendimiento general de la red en aproximadamente un 20%.
Rápida recuperación
El algoritmo de recuperación rápida 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 ejecuta ahora (es decir, la ventana de congestión cwnd no se establece en 1), pero el valor de cwnd se establece en el valor del umbral de inicio lento ssthresh reducido a la mitad, y luego el algoritmo para evitar la congestión ("La adición aumenta"), de modo que la ventana de congestión aumenta lentamente de forma lineal.