[Estereotipo de red informática] Red informática (1)

¿Cuáles son los protocolos y funciones de cada capa de la red informática?

El sistema de red informática se puede dividir aproximadamente en los siguientes tres tipos: modelo OSI de siete capas, modelo TCP/IP de cuatro capas y modelo de cinco capas.

• Modelo OSI de siete capas: grande y completo, pero más complicado, primero hay un modelo teórico y no hay una aplicación práctica.
• Modelo de cuatro capas TCP/IP: se resume en el desarrollo de aplicaciones prácticas. En esencia, TCP/IP solo tiene las tres capas superiores y la capa inferior no tiene contenido específico. El modelo de referencia TCP/IP realmente no describe esta capa realización.
• Modelo de cinco capas: el modelo de cinco capas solo aparece en el proceso de enseñanza en red informática, este es un compromiso entre el modelo de siete capas y el modelo de cuatro capas, es conciso y puede explicar el concepto con claridad.
  
  Las funciones principales de cada capa de la arquitectura de red de siete capas:

• Capa de aplicación: proporciona servicios interactivos para aplicaciones. Existen muchos protocolos de capa de aplicación en Internet, como el sistema de nombres de dominio DNS, el protocolo HTTP que admite aplicaciones World Wide Web, el protocolo SMTP que admite correo electrónico, etc.

• Capa de presentación: principal responsable de la conversión de formatos de datos, como cifrado y descifrado, conversión y traducción, compresión y descompresión, etc.

• Capa de sesión: responsable de establecer, mantener y terminar la comunicación entre dos nodos en la red. Por ejemplo, el servidor verifica que la capa de sesión complete el inicio de sesión del usuario.

• Capa de transporte: a veces traducida como capa de transporte, que proporciona servicios generales de transmisión de datos al proceso host. Esta capa tiene principalmente los dos protocolos siguientes:

  • TCP: proporciona servicios de transmisión de datos confiables y orientados a la conexión;
  • UDP: proporciona servicios de transmisión de datos sin conexión y de mejor esfuerzo, pero no garantiza la confiabilidad de la transmisión de datos.

• Capa de red: seleccione los nodos de enrutamiento y conmutación adecuados para garantizar una transmisión de datos oportuna. Incluye principalmente el protocolo IP.

• Capa de enlace de datos: la capa de enlace de datos a menudo se denomina simplemente capa de enlace. Ensamble los paquetes de datos IP transmitidos desde la capa de red en tramas y transmítalas en los enlaces de nodos adyacentes.

• Capa física: realice la transmisión transparente de flujos de bits entre nodos adyacentes y proteja las diferencias en los medios de transmisión y los métodos de comunicación tanto como sea posible.

¿La diferencia entre TCP y UDP?

	UDP	tcp
¿Está conectado?	sin conexión	orientado a la conexión
¿Es confiable?	Transmisión poco confiable, no uso de control de flujo y control de congestión	Transmisión confiable, utilizando control de flujo y control de congestión.
¿Está en orden?	fuera de servicio	Ordenado, los mensajes pueden estar desordenados durante la transmisión, TCP se reordenará
velocidad de transferencia	rápido	lento
Número de objetos de conexión	Admite comunicación interactiva uno a uno, uno a muchos, muchos a uno y muchos a muchos.	Sólo comunicación uno a uno
método de transferencia	orientado a mensajes	orientado a la corriente
cabeza arriba	La sobrecarga del encabezado es pequeña, solo 8 bytes.	El mínimo del encabezado es 20 bytes y el máximo es 60 bytes.
Escena aplicable	Adecuado para aplicaciones en tiempo real (telefonía IP, videoconferencia, transmisión en vivo, etc.)	Adecuado para aplicaciones que requieren transferencias confiables, como transferencias de archivos

Resumen : TCP se usa cuando es necesario lograr una transmisión confiable en la capa de transporte, y UDP se usa para comunicaciones que tienen altos requisitos de transmisión de alta velocidad y rendimiento en tiempo real. Se deben utilizar TCP y UDP según sea necesario según el propósito de la aplicación.

¿Cuáles son los escenarios de aplicación correspondientes a UDP y TCP?

TCP está orientado a la conexión y puede garantizar la entrega confiable de datos, por lo que a menudo se usa para:

• Transferencia de archivos FTP
• HTTP/HTTPS

UDP no tiene conexión, puede enviar datos en cualquier momento y el procesamiento de UDP en sí es simple y eficiente, por lo que a menudo se usa para:

• Comunicación con una pequeña cantidad de paquetes, como DNS, SNMP, etc.
• Vídeo, audio y otras comunicaciones multimedia.
• comunicación de difusión

protocolo de capa de aplicación	solicitud	protocolo de capa de transporte
SMTP	correo electrónico	tcp
Telnet	acceso remoto a terminales	tcp
HTTP	World Wide Web	tcp
ftp	transferencia de archivos	tcp

protocolo de capa de aplicación	solicitud	protocolo de capa de transporte
DNS	conversión de dominio	UDP
TFTP	transferencia de archivos	UDP
SNMP	administración de redes	UDP
NFS	servidor de archivos remoto	UDP

¿Explica en detalle el mecanismo de protocolo de enlace de tres vías de TCP?

• El primer apretón de manos: el cliente solicita establecer una conexión, envía un mensaje de sincronización (SYN = 1) al servidor , selecciona un número aleatorio seq = x como número de secuencia inicial y ingresa al estado SYN_SENT , esperando que el servidor confirmar.

• El segundo apretón de manos: después de recibir el mensaje de solicitud de conexión, si el servidor acepta establecer una conexión, enviará un mensaje de confirmación de sincronización (SYN = 1, ACK = 1) al cliente . El número de confirmación es ACK = x + 1, y seleccione Se utiliza un número aleatorio seq = y como número de secuencia inicial, y el servidor ingresa al estado SYN_RECV en este momento.

• El tercer apretón de manos: después de recibir la confirmación del servidor , el cliente envía un mensaje de confirmación (ACK = 1) al servidor , el número de confirmación es ack = y + 1, el número de secuencia es seq = x + 1, el cliente y El servidor ingresa al estado ESTABLECIDO y completa el protocolo de enlace de tres vías.

¿Por qué hay un apretón de manos de tres vías en lugar de dos?

• 1. Evite que el mensaje de solicitud de conexión caducada se envíe repentinamente al servidor, lo que provocará errores y desperdicio de recursos.
  En el caso de que la conexión se pueda establecer después de dos apretones de manos entre las dos partes, suponiendo que el cliente envía un segmento A solicitando establecer una conexión, A no puede comunicarse con el servidor temporalmente debido a razones de red y el servidor no devolverá una confirmación. mensaje si no puede recibir la parte del segmento de solicitud. El cliente reenvía el segmento de mensaje de solicitud B cuando no ha recibido una respuesta durante mucho tiempo. Esta vez B llega al servidor con éxito, y el servidor inmediatamente devuelve un mensaje de confirmación y entra en el estado ESTABLECIDO. Después de recibir el mensaje de confirmación, el El cliente también ingresa al estado ESTABLECIDO, las dos partes establecen una conexión y transmiten datos, y luego se desconectan normalmente.
  En este momento, el segmento de mensaje A que llega tarde llega al servidor, y el servidor inmediatamente devuelve un mensaje de confirmación y ingresa al estado ESTABLECIDO, pero el cliente que ha ingresado al estado CERRADO no puede aceptar el segmento del mensaje de confirmación, y mucho menos ingresar al Estado ESTABLECIDO, lo que hará que el servidor espere unilateralmente durante mucho tiempo, lo que provocará un desperdicio de recursos.

• Dos o tres apretones de manos pueden permitir a ambas partes confirmar que sus capacidades de envío y recepción y las de la otra parte son normales .
  El primer apretón de manos: el cliente solo envía el segmento de solicitud y no se puede confirmar nada, pero el servidor puede confirmar que su propia capacidad de recepción y la capacidad de envío de la otra parte son normales; el segundo apretón de manos: el cliente puede confirmar su propio envío capacidad
  y capacidad de recepción Normal, la capacidad de envío y recepción de la otra parte son normales;
  el tercer apretón de manos: el servidor puede confirmar que su capacidad de envío y recepción son normales, y que la capacidad de envío y recepción de la otra parte son normales ; se puede ver que el
  protocolo de enlace de tres vías puede permitir que ambas partes confirmen sus capacidades de envío y recepción y las de la otra parte. Todo es normal, para que pueda comunicarse felizmente.

• 3. Informe a la otra parte su propio valor del número de serie inicial y confirme la recepción del valor del número de serie inicial de la otra parte . Una de las razones por las que TCP logra una transmisión de datos confiable es que el campo de número de secuencia y el campo de número de secuencia de confirmación
  se mantienen en el segmento del mensaje TCP. A través de estos dos campos, ambas partes pueden saber cuál de los datos que han enviado ha sido confirmado por la otra parte .. Los valores de estos dos campos se incrementarán según el valor del número de secuencia inicial. Si se trata de un protocolo de enlace bidireccional, solo se puede confirmar el número de secuencia inicial del iniciador, mientras que el número de secuencia inicial del otro El partido no se puede confirmar.

¿Por qué un apretón de manos de tres en lugar de cuatro?

El protocolo de enlace de tres vías ya puede confirmar que las capacidades de envío y recepción de ambas partes son normales, ambas partes saben que la otra parte está lista y también pueden completar la confirmación de los números de serie iniciales de ambas partes, por lo que no es necesario un cuarto apretón de manos.

• El primer apretón de manos: el servidor confirma que la función de mensaje "recibir por sí mismo, enviar por el cliente" es normal.
• El segundo apretón de manos: el cliente confirma que la función de mensaje de "enviar por sí mismo, recibir por sí mismo, recibir por el servidor y enviar por el cliente" es normal y el cliente cree que se ha establecido la conexión.
• El tercer apretón de manos: el servidor confirma que la función de "enviar por sí mismo y recibir por el cliente" es normal, en este momento ambas partes han establecido una conexión y pueden comunicarse con normalidad.

¿Qué es un ataque de inundación SYN? ¿Cómo prevenirlo?

El ataque de inundación SYN es un tipo de ataque DOS que utiliza el defecto del protocolo TCP y consume recursos de CPU y memoria al enviar una gran cantidad de solicitudes de semiconexión.

principio:

• En el proceso de protocolo de enlace de tres vías, el segundo paso: la conexión TCP [SYN/ACK]después de que el servidor envía el paquete (el segundo paquete) y antes de recibir el [ACK]paquete del cliente (el tercer paquete) se denomina conexión medio abierta . servidor en SYN_RECVestado (sincronización recibida, esperando respuesta del cliente). Si se recibe del cliente [ACK], la conexión TCP es exitosa; de lo contrario, la solicitud se reenviará continuamente hasta que sea exitosa.
• El atacante del ataque SYN falsifica una gran cantidad de direcciones IP inexistentes en un corto período de tiempo , envía [SYN]paquetes continuamente al servidor, el servidor responde con [SYN/ACK]paquetes y espera la confirmación del cliente. Dado que la dirección de origen no existe, el servidor debe reenviar continuamente hasta que se agote el tiempo de espera.
• Estos [SYN]paquetes falsificados ocuparán la cola desconectada durante mucho tiempo, afectando el SYN normal, provocando que el sistema de destino funcione lentamente, congestión de la red e incluso parálisis del sistema.

Detección: cuando ve muchos estados semiconectados en el servidor , especialmente si la dirección IP de origen es aleatoria , básicamente puede concluir que se trata de un ataque SYN.

Prevención:

• Filtrar la protección de la puerta de enlace a través de firewalls, enrutadores, etc.
• Prevenga fortaleciendo la pila de protocolos TCP/IP, como aumentando el número máximo de semiconexiones y acortando el período de tiempo de espera.
• Tecnología de cookies SYN. Las cookies SYN son un medio para modificar el protocolo de enlace de tres vías en el lado del servidor TCP para evitar ataques de inundación SYN.

Durante la fase de conexión de protocolo de enlace de tres vías, el último paquete ACK se pierde, ¿qué pasará?

Servidor:

• El tercer ACK se pierde en la red, entonces el estado de la conexión TCP en el servidor es SYN_RECV (se ha recibido la sincronización) y, de acuerdo con el mecanismo de retransmisión del tiempo de espera de TCP, esperará 3 segundos, 6 segundos y 12 segundos. antes de reenviar el paquete SYN+ACK, para que el cliente reenvíe el paquete ACK.
• Si la respuesta ACK del cliente aún no se recibe después del número especificado de retransmisiones, el servidor cerrará automáticamente la conexión después de un período de tiempo.

cliente:

El cliente cree que se ha establecido la conexión . Si el cliente envía datos al servidor, el servidor responderá RST包con (Restablecer, restablecer el indicador, se usa para cerrar la conexión de manera anormal). En este punto, el cliente sabe que el tercer apretón de manos falló.

Describe en detalle el proceso de cuatro ondas de TCP.

• La primera ola: el cliente envía un mensaje de liberación de conexión (FIN = 1, ACK = 1) al servidor , cierra activamente la conexión y espera la confirmación del servidor.

  • Número de secuencia seq = m, es decir, el número de secuencia del último byte del mensaje enviado por el cliente la última vez + 1
  • Número de confirmación ack = n, es decir, el número de secuencia del último byte del mensaje enviado por el servidor la última vez + 1

• La segunda ola: después de recibir el mensaje de liberación de conexión, el servidor envía inmediatamente un mensaje de confirmación (ACK = 1), el número de secuencia seq = n y el número de confirmación ack = m + 1.

  • En este momento, la conexión TCP está en un estado medio cerrado, es decir, la conexión del cliente al servidor se ha liberado, pero la conexión del servidor al cliente aún no se ha liberado. Esto significa que el cliente no tiene datos para enviar, pero el servidor aún puede enviar datos al cliente.

• La tercera ola: el servidor envía un mensaje de liberación de conexión (FIN = 1, ACK = 1) al cliente , cierra activamente la conexión y espera la confirmación de A.

  • Número de secuencia seq = p, es decir, el número de secuencia del último byte del mensaje enviado por el servidor la última vez + 1.
  • Número de confirmación ack = m + 1, que es el mismo que la segunda ola, porque el cliente no ha enviado datos durante este tiempo

• La cuarta ola: después de recibir el mensaje de liberación de conexión del servidor, el cliente envía inmediatamente un mensaje de confirmación (ACK = 1), el número de secuencia seq = m + 1 y el número de confirmación es ack = p + 1.

  • En este punto, el cliente ingresa TIME-WAITal estado. Tenga en cuenta que la conexión de cliente a TCP aún no se ha liberado y entrará 2*MSLen ese estado solo después de que haya transcurrido el tiempo (vida útil más larga del segmento de mensaje) CLOSED. Siempre que el servidor reciba la confirmación del cliente, ingresará inmediatamente CLOSEDal estado. Se puede ver que el tiempo para que el servidor finalice la conexión TCP es anterior al del cliente.

¿Por qué hay un protocolo de enlace de tres vías al conectarse, pero un protocolo de enlace de cuatro vías al cerrar?

Después de que el servidor recibe el segmento FIN del cliente (la primera ola), es posible que todavía queden algunos datos por transmitir, por lo que la conexión no se puede cerrar inmediatamente, pero responderá y devolverá un segmento ACK (la segunda ola). A continuación, los datos pueden continuar enviándose. Una vez enviados los datos, el servidor enviará un mensaje FIN al cliente (la tercera ola), indicando que los datos se han enviado y solicitando cerrar la conexión. El ACK y FIN del servidor generalmente se envían por separado , lo que genera una onda más, por lo que se requieren un total de cuatro ondas.

¿Por qué el estado TIME-WAIT del cliente debe esperar 2MSL (vida útil máxima del segmento)?

1. Asegúrese de que el mensaje ACK pueda llegar al servidor, para que el servidor pueda cerrar la conexión normalmente.
   Al saludar por cuarta vez, es posible que el paquete ACK del cuarto saludo del cliente no necesariamente llegue al servidor. El servidor retransmitirá el mensaje FIN/ACK con el tiempo. Si el cliente se ha desconectado en este momento, no podrá responder a la segunda solicitud del servidor. De esta forma, el servidor no recibirá la confirmación del FIN. Mensaje /ACK durante mucho tiempo. No se puede desconectar correctamente.

   MSL es el tiempo más largo que un segmento puede vivir en la red. El cliente espera el tiempo 2MSL, es decir 【客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输】, puede recibir el mensaje FIN/ACK retransmitido por el servidor, y luego el cliente retransmite el mensaje ACK una vez y reinicia el temporizador 2MSL. Esto garantiza que el servidor se pueda apagar normalmente.

   Si el FIN reenviado por el servidor no se transmite exitosamente al cliente dentro de 2MSL, el servidor continuará agotando el tiempo de espera y reintentando hasta que se desconecte la conexión.

2. Evita que aparezcan segmentos de solicitud de conexión no válidas en conexiones posteriores.

   TCP requiere que no se utilice el mismo número de secuencia dentro de 2MSL.
   Después de que el cliente envía el último segmento de mensaje ACK y después de 2MSL, puede garantizar que todos los segmentos de mensajes generados durante la conexión desaparecerán de la red. De esta manera, dichos segmentos de solicitud de conexión antiguos no aparecerán en la siguiente conexión. O incluso si se reciben estos mensajes obsoletos, es posible que no se procesen.

¿Qué pasa si se establece la conexión, pero el cliente falla?

A través del mecanismo de reintento del temporizador + tiempo de espera , intente obtener confirmación hasta que el final se desconecte automáticamente. Específicamente, TCP tiene un temporizador de mantenimiento de actividad . Cada vez que el servidor recibe datos del cliente, el temporizador se restablecerá y el tiempo generalmente se establece en 2 horas .
Si no se reciben datos del cliente dentro de 2 horas, el servidor comenzará a reintentar: envíe un segmento de sonda cada 75 minutos, si el cliente aún no responde después de enviar 10 sondas seguidas, entonces el servidor considerará la conexión a estar cerrado desconectado.

¿Cuáles son las consecuencias de tener demasiados estados de TIEMPO-ESPERA? ¿Como lidiar con?

Desde la perspectiva del servidor, cerrar una gran cantidad de conexiones de Cliente en un corto período de tiempo provocará una gran cantidad de conexiones TIME_WAIT en el servidor, consumiendo seriamente los recursos del servidor. En este momento, algunos clientes mostrarán que no pueden conectarse. .
Desde el lado del cliente, demasiado TIME_WAIT en el lado del cliente hará que los recursos del puerto estén ocupados, porque solo hay 65536 puertos y, si están llenos, no se pueden crear nuevas conexiones.
Solución:

• El servidor puede SO_REUSEADDRevitar el estado TIME_WAIT configurando la opción de socket, esta opción de socket le dice al kernel, incluso si este puerto está ocupado (en el
  estado TIME_WAIT), continúe y reutilícelo.

• Ajustar los parámetros del kernel del sistema, modificar /etc/sysctl.confarchivos, es decir, modificar net.ipv4.tcp_tw_reuseytcp_timestamps

  # 表示开启重用。允许将 TIME-WAIT sockets 重新用于新的TCP连接，默认为0，表示关闭；
  net.ipv4.tcp_tw_reuse = 1 
  # 表示开启 TCP 连接中 TIME-WAIT sockets 的快速回收，默认为0，表示关闭。
  net.ipv4.tcp_tw_recycle = 1 
  

• Cierre a la fuerza, envíe el paquete RST para omitir el estado TIME_WAIT e ingrese directamente al estado CERRADO. El paquete RST se utiliza para cerrar por la fuerza la conexión TCP. Cuando el host necesita cerrar la conexión lo antes posible (o la conexión se agota, el puerto o el host es inalcanzable), se enviará el paquete RST.

¿TIME_WAIT es el estado del servidor o el estado del cliente?

TIME_WAIT es el estado en el que entrará la parte que se desconecta activamente . En circunstancias normales, es el estado en el que se encuentra el cliente , el servidor generalmente está configurado para no cerrar activamente la conexión.

TIME_WAIT necesita esperar 2MSL. En el caso de una gran cantidad de conexiones cortas, TIME_WAIT será demasiado, lo que también consumirá muchos recursos del sistema. Para el servidor, especifique KeepAlive en el protocolo HTTP (el navegador reutiliza una conexión TCP para manejar múltiples solicitudes HTTP) y el navegador desconecta activamente la conexión, lo que puede reducir el problema del servidor hasta cierto punto.

¿Cómo garantiza el protocolo TCP la confiabilidad?

TCP proporciona principalmente métodos como suma de verificación, número de secuencia/respuesta de reconocimiento, retransmisión de tiempo de espera, ventana deslizante, control de congestión y control de flujo para lograr una transmisión confiable.

• Suma de verificación : A través del método de suma de verificación, el extremo receptor puede detectar si hay errores o anomalías en los datos, si hay un error, descartará directamente el segmento TCP y lo reenviará.

• Número de serie/Respuesta de confirmación :

  La función del número de serie no es solo la función de la respuesta: con el número de serie, los datos recibidos se pueden ordenar según el número de serie y los datos con números de serie repetidos se pueden eliminar.
  En el proceso de transmisión TCP, cada vez que el receptor recibe datos, confirmará la respuesta al transmisor. Es decir, enviar un mensaje ACK, que contiene un número de secuencia de confirmación correspondiente, que le indica al remitente qué datos se han recibido y dónde enviar los siguientes datos.

• Ventana deslizante : La ventana deslizante no solo mejora la eficiencia de la transmisión de mensajes, sino que también evita la excepción de que el remitente envía demasiados datos y el receptor no puede manejarlos normalmente.

• Retransmisión de tiempo de espera : La retransmisión de tiempo de espera se refiere al tiempo entre el paquete de datos enviado y la recepción del paquete de confirmación. Si excede este tiempo, se considerará pérdida de paquete y deberá retransmitirse. El tiempo de espera máximo se calcula dinámicamente.

• Control de congestión : En el proceso de transmisión de datos, la congestión de la red puede deberse a problemas de estado de la red. En este momento, se introduce un mecanismo de control de congestión para mejorar el rendimiento y garantizar la confiabilidad de TCP.

• Control de flujo : si el host A sigue enviando datos al host B, independientemente de la capacidad del host B para aceptarlos, puede hacer que el búfer de recepción del host B esté lleno y no pueda aceptar datos, lo que provocará una gran pérdida de paquetes de datos y provocará la retransmisión. mecanismo. En el proceso de retransmisión, si la condición del búfer de recepción del host B aún no mejora, se perderá mucho tiempo retransmitiendo datos, lo que reducirá la eficiencia de la transmisión de datos. Por lo tanto, se introduce el mecanismo de control de flujo y el host B le dice al host A el tamaño de su propio búfer de recepción, de modo que el host A pueda controlar la cantidad de datos enviados. El control de flujo está relacionado con el tamaño de la ventana en el encabezado del protocolo TCP .

¿Cuénteme en detalle sobre la ventana deslizante de TCP?

Durante la transmisión de datos, si los datos transmitidos son relativamente grandes, es necesario dividirlos en varios paquetes de datos para su transmisión. El protocolo TCP necesita confirmar los datos antes de enviar el siguiente paquete de datos. De esta forma, se perderá tiempo esperando el enlace del paquete de acuse de recibo. Para evitar esta situación, TCP introduce el concepto de ventana. El tamaño de la ventana se refiere al valor máximo que puede continuar enviando paquetes de datos sin esperar un paquete de confirmación.

El lado izquierdo de la ventana deslizante es el paquete que ha sido enviado y confirmado , y el lado derecho de la ventana deslizante es el paquete que aún no ha llegado .

La ventana deslizante también se divide en dos partes: una son los paquetes que se han enviado pero no confirmados y la otra son los paquetes que esperan ser enviados en la ventana .
Como los paquetes enviados se confirman continuamente, los paquetes que esperan ser enviados dentro de la ventana también se enviarán continuamente. Toda la ventana se moverá hacia la derecha, permitiendo que los grupos que aún no han tenido su turno entren a la ventana.

Se puede ver que la ventana deslizante juega un papel de limitación actual , es decir, el tamaño de la ventana deslizante actual determina la velocidad a la que TCP envía paquetes , y el tamaño de la ventana deslizante depende del mínimo entre la congestión. ventana de control y la ventana de control de flujo .

¿Cuéntame sobre el control de la congestión en detalle?

TCP utiliza un total de cuatro algoritmos para lograr el control de la congestión :

• inicio lento (inicio lento);

• Evitar la congestión (evitar la congestión);

• retransmisión rápida ;

• Rápida recuperación .

El remitente mantiene una cwndvariable de estado llamada ventana de congestión. Cuando el valor de cwnd disminuye hasta el umbral inicial de reducción de la ventana de congestión cwndssthresh, se utiliza en su lugar el algoritmo para evitar la congestión.

Inicio lento : no envíe una gran cantidad de datos al principio y aumente gradualmente el tamaño de la ventana de congestión de pequeña a grande.

Evitar la congestión : El algoritmo para evitar la congestión hace que la ventana de congestión crezca lentamente, es decir, la ventana de congestión del remitente cwnd+1 no se duplica cada vez que pasa un tiempo de ida y vuelta RTT. De esta forma, la ventana de congestión crece lentamente según una ley lineal.

Retransmisión rápida : podemos eliminar algunos paquetes congestionados innecesarios y mejorar el rendimiento de la red. Por ejemplo, el receptor envía una confirmación repetida inmediatamente después de recibir un segmento fuera de secuencia, en lugar de esperar la confirmación al enviar datos. Reglas de retransmisión rápida: siempre que el remitente reciba tres acuses de recibo repetidos seguidos, debe retransmitir inmediatamente el segmento del mensaje que la otra parte no ha recibido, sin tener que seguir esperando a que expire el temporizador de retransmisión establecido.

Recuperación rápida : principalmente junto con una retransmisión rápida. Cuando el remitente recibe tres confirmaciones repetidas seguidas, ejecuta el algoritmo de "reducción multiplicativa" para reducir el ssthreshumbral (para evitar la congestión de la red), pero luego no ejecuta el algoritmo de inicio lento , porque si la red está congestionada, No recibirá varias confirmaciones repetidas y recibir tres confirmaciones repetidas indica que la condición de la red es correcta.