Computer Network Notes-4 (Explicación detallada del protocolo TCP)

Encabezado TCP

La estructura del encabezado TCP se muestra en la figura

• El número de puerto de 16 bits almacena los puertos de origen y destino. Para la comunicación TCP, el cliente utiliza el número de puerto temporal seleccionado automáticamente por el sistema y el servidor utiliza el número de puerto de servicio conocido (los números de puerto utilizados por todos los servicios conocidos se definen en / etc / services).

• Un número de secuencia de 32 bits, el número de cada byte de un flujo de bytes en una dirección de transmisión El número de secuencia inicial es un valor aleatorio ISN (Número de secuencia inicial) inicializado por el sistema. Tenga en cuenta que un segmento de TCP contiene un fragmento de datos y su valor de número de secuencia es el valor de número de secuencia del primer byte.

• Un número de confirmación de 32 bits. Si A y B están en comunicación TCP, el segmento TCP enviado por A no solo lleva su propio número de serie, sino que también contiene el número de confirmación del segmento TCP enviado por B. El valor del número de acuse de recibo es el valor del número de secuencia del segmento TCP recibido más uno.

• La longitud del encabezado de 4 bits indica cuántos 4 bytes tiene el encabezado TCP. El encabezado TCP máximo es de 15 * 4 bytes.

• La bandera de 6 bits contiene los siguientes elementos:

  1. La bandera URG indica si el puntero de emergencia es válido.
  2. La bandera ACK indica si el número de confirmación es válido. El segmento TCP que lleva la bandera ACK se denomina segmento de reconocimiento.
  3. El indicador PSH indica que la aplicación receptora debe leer inmediatamente los datos del área de búfer de recepción de TCP para dejar espacio para los datos posteriores (si no se lee, siempre permanecerá en el área de búfer de recepción de TCP)
  4. El signo RST indica que la otra parte debe restablecer la conexión. El segmento de TCP que lleva la bandera RST se denomina segmento de reinicio.
  5. La bandera SYN indica que se solicita una conexión. Se llama segmento de sincronización.
  6. La bandera FIN indica que se notifica a la otra parte que la conexión se cerrará. Se llama segmento final.

• El tamaño de la ventana de 16 bits se utiliza para el control de flujo. La ventana aquí es la Ventana del receptor (RWND). Se utiliza para decirle a la otra parte cuántos bytes de datos se pueden acomodar en el área de búfer de recepción del extremo local, de modo que la otra parte pueda controlar la velocidad de envío de datos.

• El remitente completa la suma de verificación de 16 bits y el receptor usa el algoritmo CRC para verificar (no solo verifica el encabezado, sino también los datos).

• El puntero de emergencia de 16 bits es una compensación. El valor del número de secuencia del segmento más esta compensación representa el número de secuencia de un dato de emergencia, que es utilizado por el remitente para enviar datos de emergencia al receptor.

El anterior es un campo fijo, que ocupa 20 bytes, y los siguientes 40 bytes son el campo de opción

Protocolo de enlace de tres vías TCP

El proceso de protocolo de enlace de tres vías TCP se muestra en la figura. El

protocolo de enlace de tres vías en realidad significa que cuando se establece una conexión TCP, el cliente y el servidor deben enviar un total de 3 paquetes. La función principal del protocolo de enlace de tres vías es confirmar si las capacidades de recepción y envío de ambas partes son normales y especificar su propio número de secuencia de inicialización para prepararse para la transmisión confiable posterior. La esencia del puerto designado está realmente conectado a un servidor, establecer una conexión TCP, conectar y sincronizar tanto la secuencia como los números de reconocimiento, intercambiar información sobre el tamaño de la ventana TCP .

Suponiendo que el cliente está en el estado Cerrado y el servidor está en el estado Escuchar al principio, el proceso detallado del protocolo de enlace de tres vías es el siguiente:

• El primer apretón de manos: el cliente envía un mensaje SYN al servidor e indica el número de secuencia inicial ISN del cliente. En este momento, el cliente se encuentra en el estado SYN_SENT.

  El bit de sincronización del encabezado SYN = 1, el número de secuencia inicial seq = x y el segmento de SYN = 1 no pueden transportar datos, pero consume un número de secuencia.

• Segundo protocolo de enlace: después de que el servidor recibe el mensaje SYN del cliente, responderá con su propio mensaje SYN y también especificará su propio número de secuencia de inicialización ISN. Al mismo tiempo, el ISN + 1 del cliente se utilizará como valor ACK, lo que indica que ha recibido el SYN del cliente y que el servidor está en el estado SYN_RCVD.

  En el segmento de confirmación, SYN = 1, ACK = 1, número de confirmación ack = x + 1 y número de secuencia inicial seq = y.

• El tercer protocolo de enlace: después de que el cliente recibe el mensaje SYN, enviará un mensaje ACK. Por supuesto, el ISN + 1 del servidor es el mismo que el valor ACK, lo que indica que ha recibido el mensaje SYN del servidor. En este momento, el cliente En estado ESTABLECIDO. Una vez que el servidor recibe el mensaje ACK, también se encuentra en el estado ESTABLECIDO En este momento, las dos partes han establecido una conexión.

  Segmento de reconocimiento ACK = 1, número de reconocimiento ack = y + 1, número de secuencia seq = x + 1 (inicialmente seq = x, por lo que el segundo segmento debe ser +1), el segmento ACK puede transportar datos, no Los datos de transporte no consumen el número de serie.

El extremo que envía el primer SYN realizará una apertura activa, y el otro extremo que recibe este SYN y lo envía de regreso al siguiente SYN realizará una apertura pasiva.

En la programación de socket, cuando el cliente ejecuta connect (), se activará un protocolo de enlace de tres vías.

Razones para el apretón de manos de "tres vías"

El propósito de cada apretón de manos es el siguiente:

• El primer apretón de manos: el cliente envía un paquete de red y el servidor lo recibe.
  De esta manera, el servidor puede concluir que la capacidad de envío del cliente y la capacidad de recepción del servidor son normales.
• El segundo apretón de manos: el servidor envía el paquete y el cliente lo recibe.
  De esta manera, el cliente puede concluir que las capacidades de recepción y envío del servidor y las capacidades de recepción y envío del cliente son normales. Sin embargo, en este momento, el servidor no puede confirmar si la capacidad de recepción del cliente es normal.
• El tercer apretón de manos: el cliente envía el paquete y el servidor lo recibe.
  De esta manera, el servidor puede concluir que las capacidades de envío y recepción del cliente son normales y que las capacidades de envío y recepción del propio servidor también son normales.

Por lo tanto, se requiere un protocolo de enlace de tres vías para confirmar si las capacidades de recepción y envío de ambas partes son normales.

Cola semiconectada

Después de que el servidor reciba el SYN del cliente por primera vez, estará en el estado SYN_RCVD. En este momento, las dos partes no han establecido completamente su conexión. El servidor pondrá la conexión de solicitud en este estado en una cola. A esta cola la llamamos cola semiconectada .

Por supuesto, también hay una cola completamente conectada , es decir, se ha completado el protocolo de enlace de tres vías, y aquellos que han establecido una conexión se colocarán en la cola completamente conectada. Si la cola está llena, puede ocurrir la pérdida de paquetes.

Con respecto al número de retransmisiones SYN-ACK: Después de que el
servidor envía el paquete SYN-ACK, si no recibe el paquete de confirmación del cliente, el servidor retransmite por primera vez, espera un período de tiempo y no recibe la confirmación del cliente. paquete, y luego realiza la segunda retransmisión. Si el número de retransmisiones excede el número máximo de retransmisiones especificado por el sistema, el sistema borra la información de conexión de la cola de semiconexión.
Tenga en cuenta que el tiempo de espera para cada retransmisión no es necesariamente el mismo, generalmente aumentará exponencialmente, por ejemplo, el tiempo de intervalo es 1s, 2s, 4s, 8s ...

ISN

Cuando un extremo envía su SYN para establecer una conexión, elige un número de secuencia inicial para la conexión. El ISN cambia con el tiempo, por lo que cada conexión tendrá un ISN diferente. El ISN se puede considerar como un contador de 32 bits, que aumenta en 1 cada 4 ms. El propósito de seleccionar el número de secuencia de esta manera es evitar que el paquete retrasado en la red se transmita en el futuro, lo que puede hacer que una parte conectada lo interprete incorrectamente.

Una de las funciones importantes del protocolo de enlace de tres vías es que el cliente y el servidor intercambian ISN (Número de secuencia inicial) para que la otra parte sepa cómo ensamblar los datos de acuerdo con el número de secuencia cuando reciba los datos a continuación. Si el ISN es fijo, el atacante puede adivinar fácilmente el número de confirmación posterior, por lo que el ISN se genera dinámicamente.

Llevar datos

El tercer apretón de manos puede transportar datos. Pero el primer y segundo apretón de manos no pueden transportar datos

Si el primer apretón de manos puede transportar datos, si alguien quiere atacar maliciosamente el servidor, pondrá una gran cantidad de datos en el mensaje SYN en el primer apretón de manos cada vez. Porque el atacante simplemente ignora si las capacidades de recepción y envío del servidor son normales, y luego repite frenéticamente el envío de mensajes SYN, lo que hará que el servidor dedique mucho tiempo y espacio de memoria para recibir estos mensajes.

Ataque SYN

La asignación de recursos en el lado del servidor se asigna durante el segundo protocolo de enlace, y los recursos del lado del cliente se asignan cuando se completa el protocolo de enlace de tres vías , por lo que el servidor es vulnerable a los ataques de inundación SYN.

El ataque SYN consiste en que el cliente falsifica una gran cantidad de direcciones IP inexistentes en un corto período de tiempo y envía continuamente paquetes SYN al servidor, y el servidor responde con paquetes de confirmación y espera a que el cliente confirme. La dirección de origen no existe, el servidor debe retransmitir hasta que expire el tiempo de espera. Estos paquetes SYN falsificados ocuparán la cola no conectada durante mucho tiempo, lo que provocará que las solicitudes SYN normales se descarten porque la cola está llena, lo que provoca congestión de la red e incluso parálisis del sistema. . El ataque SYN es un ataque DoS / DDoS típico.

Es muy conveniente detectar ataques SYN.Cuando ve una gran cantidad de estados semi-conectados en el servidor, especialmente la dirección IP de origen es aleatoria, básicamente puede concluir que se trata de un ataque SYN. En Linux / Unix, puede usar el comando netstat que viene con el sistema para detectar ataques SYN.

netstat -n -p TCP | grep SYN_RECV

Los métodos habituales para defenderse de los ataques SYN son los siguientes:

• Acortar el tiempo de espera de SYN
• Aumentar el número máximo de semiconexiones.
• Protección de la puerta de enlace del filtro
• Tecnología de cookies SYN

TCP saludó cuatro veces

El proceso de las cuatro ondas de

manos de TCP se muestra en la figura. Establecer una conexión requiere tres apretones de manos, y terminar una conexión requiere cuatro ondas de manos. Esto es causado por el TCP medio-close resultado (media de cerca) a. El llamado medio cierre, de hecho, es que TCP proporciona la capacidad de que un extremo de la conexión reciba datos del otro extremo después de que termine de enviarlos.
Tanto el cliente como el servidor pueden iniciar activamente una acción de oleada. Al principio, ambas partes se encuentran en el estado ESTABLECIDO, si el cliente inicia primero una solicitud de apagado. El proceso de agitar cuatro veces es el siguiente:

• Ola por primera vez: el cliente envía un mensaje FIN con un número de serie especificado en el mensaje. En este momento, el cliente se encuentra en el estado FIN_WAIT1.

  Es decir, se envía el segmento de liberación de conexión (FIN = 1, número de secuencia seq = u) y los datos se detienen nuevamente, la conexión TCP se cierra activamente y se ingresa al estado FIN_WAIT1 (terminación en espera 1), esperando el confirmación del servidor.

• Segunda oleada: después de recibir el FIN, el servidor enviará un mensaje ACK y utilizará el valor del número de serie del cliente + 1 como el valor del número de serie del mensaje ACK, lo que indica que se ha recibido el mensaje del cliente. En este momento, el servidor En estado CLOSE_WAIT.

  Es decir, el servidor envía un segmento de reconocimiento (ACK = 1, número de confirmación ack = u + 1, número de secuencia seq = v) después de recibir el segmento de liberación de conexión, y el servidor entra en el estado CLOSE_WAIT (espera cerrada). En este momento , TCP En el estado medio cerrado, se libera la conexión del cliente al servidor. Después de recibir la confirmación del servidor, el cliente entra en el estado FIN_WAIT2 (terminación en espera 2) y espera el segmento del mensaje de liberación de conexión enviado por el servidor.

• Tercera ola: si el servidor también quiere desconectarse, al igual que la primera ola del cliente, envíe un mensaje FIN y especifique un número de serie. En este momento, el servidor se encuentra en el estado LAST_ACK.

  Es decir, el servidor no tiene datos para enviar al cliente, el servidor envía un segmento de liberación de conexión (FIN = 1, ACK = 1, número de secuencia seq = w, número de confirmación ack = u + 1) y el servidor ingresa LAST_ACK (confirmación final)) Estado, esperando confirmación del cliente.

• Cuarta oleada: después de recibir el FIN, el cliente envía un mensaje ACK como respuesta y utiliza el valor del número de serie del servidor + 1 como el valor del número de serie de su propio mensaje ACK. En este momento, el cliente se encuentra en el estado TIME_WAIT. Se necesita un tiempo para asegurarse de que el servidor entrará en el estado CERRADO después de recibir su propio mensaje ACK. Después de que el servidor reciba el mensaje ACK, cerrará la conexión y estará en el estado CERRADO.

  Es decir, después de que el cliente recibe el segmento de liberación de conexión del servidor, envía un segmento de reconocimiento (ACK = 1, seq = u + 1, ack = w + 1) y el cliente entra en el estado TIME_WAIT (tiempo de espera). En este momento, el TCP no se libera y el cliente entra en el estado CERRADO una vez transcurrido el tiempo 2MSL establecido por el temporizador de espera.

Recibir un FIN solo significa que no hay flujo de datos en esta dirección. Es normal que el cliente realice un apagado activo e ingrese TIME_WAIT. El servidor generalmente realiza un apagado pasivo y no ingresará al estado TIME_WAIT.

En la programación de sockets, cualquier parte realiza una operación close () para generar una operación de onda.

Razones para agitar "cuatro veces"

Cuando el servidor recibe el mensaje de solicitud de conexión SYN del cliente, puede enviar directamente el mensaje SYN + ACK. El mensaje ACK se usa para responder y el mensaje SYN se usa para sincronización. Pero cuando se cierra la conexión, cuando el servidor recibe el mensaje FIN, es posible que no cierre inmediatamente SOCKET, por lo que solo puede responder con un mensaje ACK primero y decirle al cliente: "Recibí el mensaje FIN que enviaste". Solo después de que se hayan enviado todos los mensajes de mi servidor, puedo enviar mensajes FIN, por lo que no puedo enviarlos juntos. Por lo tanto, se requieren cuatro ondas.

Estado TIME_WAIT

Cada implementación de TCP específica debe elegir una vida útil máxima de segmento de mensaje MSL (vida útil máxima de segmento), que es el tiempo más largo en la red antes de que se descarte cualquier segmento de mensaje. Este tiempo es limitado porque los segmentos TCP se transmiten en la red como datagramas IP y los datagramas IP tienen un campo TTL que limita su vida útil.

Para un valor MSL dado para una implementación específica, el principio de procesamiento es: cuando TCP realiza un cierre activo y envía el último ACK, la conexión debe permanecer en el estado TIME_WAIT por 2 veces el MSL. Esto permite que TCP envíe el último ACK nuevamente para evitar que este ACK se pierda (el otro finaliza el tiempo de espera y reenvía el último FIN).

Otro resultado de esta espera de 2MSL es que el socket que define esta conexión (la dirección IP del cliente y el número de puerto, la dirección IP del servidor y el número de puerto) ya no se puede usar durante el período de espera de 2MSL de esta conexión TCP. Esta conexión solo se puede utilizar después del final de 2MSL.

Esperando el significado de 2MSL

Para asegurar que el último segmento ACK enviado por el cliente pueda llegar al servidor. Debido a que este ACK puede perderse, el servidor en el estado ÚLTIMO-ACK no puede recibir el mensaje de confirmación FIN-ACK. El servidor retransmitirá FIN-ACK después de un tiempo de espera, y luego el cliente retransmitirá un acuse de recibo y reiniciará el temporizador de tiempo de espera. Finalmente, tanto el cliente como el servidor se pueden cerrar normalmente. Suponga que el cliente no espera 2MSL, sino que libera el cierre directamente después de enviar el ACK. Una vez que se pierde el ACK, el servidor normalmente no puede entrar en el estado de conexión cerrada.

Dos razones:

1. Asegúrese de que el último segmento ACK enviado por el cliente pueda llegar al servidor.
   Este segmento ACK puede perderse, por lo que B en el estado LAST-ACK no puede recibir la confirmación del segmento FIN + ACK enviado. El servidor retransmite el segmento FIN + ACK a lo largo del tiempo, y el cliente puede después de recibir este FIN + ACK retransmitido segmento dentro de 2MSL, el cliente retransmite un acuse de recibo, reinicia el temporizador de 2MSL y, finalmente, tanto el cliente como el servidor entran en el estado CERRADO. Si el cliente está en el estado de TIEMPO-ESPERA No espere un período de tiempo, pero libere la conexión Inmediatamente después de enviar el segmento ACK, no podrá recibir el segmento FIN + ACK retransmitido por el servidor, por lo que el segmento de confirmación no se enviará nuevamente y el servidor no será normal Ingrese al estado CERRADO.

2. Evite que aparezca "segmento de mensaje de solicitud de conexión fallida" en esta conexión.
   Una vez que el cliente termine de enviar el último segmento ACK, después de 2MSL, todos los segmentos generados durante la duración de esta conexión pueden desaparecer de la red, por lo que este no aparecerá en la próxima conexión nueva Un segmento de solicitud de conexión antigua.

Proceso de transferencia de estado TCP

El proceso de transición de estado de TCP se muestra en la figura. La

línea de puntos gruesa representa la transición de estado de la conexión del lado del servidor y la línea continua gruesa representa la transición de estado de la conexión del cliente.

Confiabilidad de TCP

TCP utiliza mecanismos como el número de secuencia, la respuesta de reconocimiento, la retransmisión de tiempo de espera, el control de ventana y el control de congestión para garantizar la confiabilidad.

Número de secuencia, respuesta de confirmación, retransmisión de tiempo de espera

Cuando los datos llegan al receptor, el receptor necesita enviar una respuesta de confirmación para indicar que se ha recibido el segmento de datos, y el número de secuencia de confirmación indicará el número de secuencia de datos que necesita recibir a continuación. Si el remitente no recibe la respuesta de confirmación tarde, es posible que se pierdan los datos enviados o se pierda la respuesta de confirmación, en este momento el remitente volverá a transmitir después de esperar un cierto período de tiempo.

Control de ventana y control de retransmisión de alta velocidad / retransmisión rápida (respuesta de confirmación repetida)

TCP usará el control de ventana para aumentar la velocidad de transmisión, lo que significa que dentro de un tamaño de ventana, no tienes que esperar una respuesta para enviar el siguiente dato. El tamaño de ventana es el valor máximo que puede continuar enviando datos. sin esperar confirmación. Si no se utiliza el control de ventana, todos los datos que no hayan recibido una respuesta de confirmación deben retransmitirse.
Usando el control de ventana, si el segmento de datos 1001-2000 se pierde, cada vez que se transmiten los datos subsiguientes, la respuesta de confirmación enviará continuamente una respuesta con el número de secuencia 1001, indicando que deseo recibir los datos a partir de 1001. Si el El remitente recibe la misma respuesta tres veces, se reenviará inmediatamente.

Control de la congestión

Si la ventana está configurada para ser grande y el remitente envía continuamente una gran cantidad de datos, puede causar congestión o incluso parálisis de la red. Por tanto, TCP realiza un control de la congestión para prevenir esta situación.

• Inicio lento (inicio lento): defina la ventana de congestión (cwnd), establezca el tamaño de la ventana en 1 al principio (generalmente establezca el tamaño en 2-4 SMSS, el tamaño máximo del segmento de datos del remitente) y luego reciba un acuse de recibo cada vez (después de un rtt), el tamaño de la ventana de congestión * 2.
• Evitación de congestión: establezca el umbral de inicio lento (ssthresh), generalmente establecido en 65536 al principio (16 en la figura). Evitar la congestión significa que cuando el tamaño de la ventana de congestión alcanza este umbral, el valor de la ventana de congestión ya no aumenta exponencialmente, sino que aumenta de forma incremental (cada respuesta de confirmación / cada rtt, tamaño de la ventana de congestión +1) para evitar la congestión.
  Con respecto a la retransmisión de tiempo de espera del segmento de mensaje como congestión, una vez que se produce una retransmisión de tiempo de espera, primero debemos establecer el umbral a la mitad del tamaño de la ventana actual, y establecer el tamaño de la ventana en el valor inicial 1, y luego volver a ingresar el lento iniciar el proceso.
• Retransmisión rápida: cuando se encuentran 3 respuestas de confirmación repetidas (control de retransmisión de alta velocidad), significa que se han recibido 3 segmentos de mensaje, pero el segmento anterior se pierde y se retransmitirá inmediatamente. El proceso de retransmisión rápida y recuperación rápida es el siguiente:
  1. Cuando se recibe el tercer segmento de confirmación repetido, cambie ssthresh, ssthresh = max (FlightSize / 2, 2 * SMSS), y retransmita inmediatamente el segmento perdido, cwnd = ssthresh + 3 * SMSS
  2. Cada vez que se recibe un segmento de mensaje de confirmación duplicado, cwnd = cwnd + SMSS. En este momento, el remitente puede enviar un nuevo segmento TCP (si el nuevo cwnd lo permite).
  3. Cuando reciba la confirmación de nuevos datos, configure cwnd = ssthresh (ssthresh es el nuevo umbral de inicio lento calculado en el primer paso).

Esto se puede lograr: durante la comunicación TCP, el rendimiento de la red aumenta gradualmente y, a medida que la congestión reduce el rendimiento y luego entra en el proceso de aumento lento, la red no se paralizará fácilmente.

El algoritmo de control de congestión mencionado en este artículo está desactualizado y el algoritmo BBR de Google ahora se usa comúnmente.

Algoritmo BBR

El algoritmo BBR tiene dos características:

1. La retroalimentación es pobre. Por ejemplo, Cubic ha implementado un mecanismo de realce de ventana alto basado en la curva convexo-cóncava de la ecuación cúbica, pero esta caída de diente de sierra es demasiado fuerte y la estrategia para evitar el bloqueo es demasiado conservadora (conservadora violenta) .
2. El algoritmo de congestión es asumida.
   Cuando la pérdida detecta mecanismo de control de paquetes TCP congestión (es decir RTO o N repitió ACKs, etc.), TCP tendrá completamente sobre el algoritmo de control de congestión y controlar la ventana de congestión por sí mismo. Sin embargo, el problema es que esta pérdida de paquetes puede no ser una pérdida de paquetes real, es solo que TCP considera una pérdida de paquetes.

En términos generales, la lógica de control de congestión antes de BBR se dividirá en dos etapas en el proceso de ejecución, a saber, la etapa normal y la etapa anormal. En la fase normal, el algoritmo de control de congestión modular de TCP domina el ajuste de la ventana. En la fase anormal, la máquina de estado de control de congestión del núcleo de TCP asume el cálculo de la ventana del algoritmo de control de congestión. La lógica es la siguiente:

static void tcp_cong_control(struct sock *sk, u32 ack, u32 acked_sacked,  int flag)  
{  
    if (tcp_in_cwnd_reduction(sk)) { // 异常模式  
        /* Reduce cwnd if state mandates */  
        // 在进入窗口下降逻辑之前，还需要tcp_fastretrans_alert来搜集异常信息并处理异常过程。  
        tcp_cwnd_reduction(sk, acked_sacked, flag);  
    } else if (tcp_may_raise_cwnd(sk, flag)) { // 正常模式或者安全的异常模式！  
        /* Advance cwnd if state allows */  
        tcp_cong_avoid(sk, ack, acked_sacked);  
    }  
    tcp_update_pacing_rate(sk);  
}  

BBR ya no permite que la máquina de estado de control de congestión se haga cargo en modo anormal:

static void tcp_cong_control(struct sock *sk, u32 ack, u32 acked_sacked,  int flag, const struct rate_sample *rs)  
{  
    const struct inet_connection_sock *icsk = inet_csk(sk);  
    // 这里是新逻辑，如果回调中宣称自己有能力解决任何拥塞问题，那么交给它 
    if (icsk->icsk_ca_ops->cong_control) {  
        icsk->icsk_ca_ops->cong_control(sk, rs);  
        // 直接return！TCP核心不再过问。  
        return;  
    }  
    // 这是老的逻辑。  
    if (tcp_in_cwnd_reduction(sk)) {  
        /* Reduce cwnd if state mandates */  
        // 如果不是Open状态...记住，tcp_cwnd_reduction并不受拥塞控制算法控制
        tcp_cwnd_reduction(sk, acked_sacked, flag);  
    } else if (tcp_may_raise_cwnd(sk, flag)) {  
        /* Advance cwnd if state allows */  
        tcp_cong_avoid(sk, ack, acked_sacked);  
    }  
    tcp_update_pacing_rate(sk);  
}  

BBR recopila continuamente el ancho de banda máximo max-bw y el mínimo RTT min-rtt en la ventana de tiempo de la conexión, y calcula la velocidad de transmisión y la ventana de congestión basándose en esto, y ajusta el coeficiente de ganancia de acuerdo con el ancho de banda real de retroalimentación bw y max. -rtt.

El algoritmo BBR elimina los alias innecesarios. Este tipo de diente de sierra es simplemente la fuente de energía de TCP antes de BBR. Varios algoritmos aumentan ciegamente la ventana. Una vez que TCP piensa que se produce la pérdida de paquetes (aunque puede que no sea una verdadera pérdida de paquetes. Por lo tanto, existen varios mecanismos cada vez más complejos. ejemplo, DSACK y similares ...), después de dejar un ssthresh, toda la lógica se hace cargo, y aquí es donde está la punta del diente dentado. De hecho, el diente de sierra está formado por el "traspaso de trabajo" entre la lógica de control de la máquina de estado de congestión de TCP y el algoritmo de control de congestión de TCP cuando ocurre un evento de congestión. El algoritmo BBR cancela este traspaso innecesario, por lo que el diente de sierra naturalmente se vuelve romo. aplanado.
No es que Vegas, CUBIC, etc. no puedan detectar la congestión, pero TCP no les da toda la potencia. En realidad, esta puede ser la práctica en la implementación de TCP original, como el concepto de ssthresh, que en realidad no es necesario en muchos algoritmos. BBR no usa ssthresh (ssthresh refleja el acoplamiento entre el algoritmo de congestión y la máquina de estado de congestión TCP. BBR no tiene este acoplamiento, por lo que ssthresh no es necesario).

Cuatro agitando dibujar apretón de manos de tres vías artículo de Ape Valley