Directorio de artículos
- Prefacio
- 1. Servicios prestados por la capa de transporte.
- 2. protocolo UDP
- 3. protocolo TCP
-
- 3.1 Características del protocolo TCP y formato de mensaje.
- 3.2 Gestión de conexiones TCP
- 3.3 Transmisión confiable TCP
- 3.4 Control de flujo TCP
- 3.5 Control de congestión TCP
-
- 3.5.2 Comprender el control de congestión y su diferencia con el control de flujo
- 3.5.3 Cuatro algoritmos para el control de la congestión
Prefacio
Actualmente preparándome para el examen de ingreso de posgrado 24, ahora resumiré y organizaré los puntos de conocimiento aprendidos en 408 de 24 Computer Kings.
Índice del directorio de artículos del blog de Blogger: índice del directorio de blogs (actualizado continuamente)
1. Servicios prestados por la capa de transporte.
1.1 Funciones de la capa de transporte
La capa de transporte es una capa que solo tienen los hosts.
Funciones de la capa de transporte :
1. La capa de transporte proporciona comunicación lógica entre procesos.
- Comunicación lógica: en la superficie, es comunicación entre procesos de dos hosts. En la comunicación real, el remitente primero lo encapsulará paso a paso desde la capa superior a la capa física, colocará el flujo de bits en el enlace para su transmisión y luego pasar por el proceso intermedio: varios sistemas intermedios finalmente llegan al host y se desencapsulan paso a paso, y finalmente la aplicación especificada solicita los datos.
- La capa de red proporciona comunicación lógica entre hosts.
2. Reutilizar y desutilizar.
- Por ejemplo: los datos enviados por WeChat y QQ eventualmente utilizarán el mismo protocolo de capa de transporte para la transmisión (multiplexación), y el teléfono móvil de destino dividirá el datagrama en la capa de transporte al mismo tiempo y lo pasará a diferentes aplicaciones (para uso separado).
3. La capa de transporte realiza la detección de errores en los mensajes recibidos.
- La etapa de la capa de red contiene una verificación del encabezado, que se utiliza para verificar el encabezado del datagrama IP. La razón por la cual no existe una función de detección de errores es porque la capa de transporte superior realizará la detección de errores en el segmento de la capa de transporte. Para la capa de transporte + capa de red, se puede realizar una función de transmisión confiable.
- La transmisión confiable no es necesariamente posible en la capa de transporte porque incluye UDP y TCP, entre los cuales TCP garantiza una transmisión confiable.
1.2 Dos protocolos en la capa de transporte (TCP, UDP)
Los dos protocolos son : TCP, UDP. El primero es confiable, el segundo no es confiable.
Comparación de protocolos TCP y UDP :
① TCP: Protocolo de control de transmisión orientado a conexión .
- Proceso de transmisión de datos : Se debe establecer una conexión antes de la transmisión de datos y la conexión debe liberarse una vez completada la transmisión de datos. No se proporcionan servicios de transmisión o multidifusión.
- Dado que TCP necesita proporcionar servicios de transmisión confiables orientados a la conexión, inevitablemente agrega muchos gastos generales: confirmación, control de flujo, temporizadores y administración de conexiones, etc.
- ¿Es confiable ? Conexión confiable, cara a cara, gran retraso.
- Escenario de aplicación : Adecuado para archivos grandes.
② UDP: Protocolo de datagramas de usuario sin conexión UDP.
- Proceso de transmisión de datos : No es necesario establecer una conexión antes de transmitir datos y no se requiere confirmación después de recibir el mensaje UDP.
- Fiabilidad : poco fiable, sin conexión, pequeño retraso.
- Escenario de aplicación : Adecuado para archivos pequeños.
1.3 Direccionamiento y puertos de la capa de transporte (introducción a los puertos comunes)
Reutilizar y deusar :
复用: Todos los procesos de aplicación en la capa de aplicación se pueden transmitir a la capa de red a través de la capa de transporte.分用: La capa de transporte entrega los datos al proceso de aplicación especificado después de recibir los datos de la capa de red.
Puerto : SAP en la capa de transporte, utilizado para identificar el proceso de aplicación en el host. Cada proceso de aplicación tendrá un número de puerto cuando se ejecute.
- Dividido principalmente en : puerto lógico/puerto de software, que se refiere al puerto del proceso de aplicación. Para los puertos de hardware, se refiere a algunas interfaces de la placa base en el mundo físico real.
- Relación de puerto : los números de puerto solo tienen significado local y no hay conexión entre los mismos puertos en diferentes computadoras en Internet.
- Longitud del número de puerto : 16 bits, que pueden representar 65536 puertos diferentes.
Los números de puerto se dividen según el rango : incluido el número de puerto del servidor y el número de puerto utilizado por el cliente.
Algunos de los puertos comunes utilizados por los servicios de aplicaciones fijas son los siguientes :
Se utiliza una combinación de sockets de remitente y receptor para identificar puntos finales en la red .
Socket : identifica de forma única un host en la red y un proceso en él.
套接字Socket = （主机IP地址，端口号）, donde la dirección IP del host puede identificar y ubicar un host en una red, mientras que el número de puerto se usa para representar un proceso en el host.
2. protocolo UDP
2.1 Comprender las funciones y características de UDP
Función UDP : solo proporciona algunas funciones además de los servicios de datagramas IP, como funciones de multiplexación, demultiplexación y detección de errores.
Características principales de UDP :
1. UDP no tiene conexión , lo que reduce la sobrecarga y el retraso antes de enviar datos.
2. UDP utiliza la entrega con el mejor esfuerzo, lo que significa que no se garantiza una entrega confiable .
- Si el protocolo UDP no puede garantizar una entrega confiable, entonces la entrega confiable se deja en manos de la capa de aplicación superior de la capa de transporte para garantizar una entrega confiable y secuencial.
3. UDP está orientado a mensajes y es adecuado para aplicaciones de red que transmiten una pequeña cantidad de datos a la vez.
No importa cuánto tiempo la capa de aplicación envíe mensajes UDP, UDP los enviará como de costumbre, es decir, un mensaje completo a la vez . Dado que tampoco es una entrega confiable, puede provocar fácilmente la pérdida de datos. Si la cantidad de datos transmitidos es no son grandes, incluso si se produce una pérdida. Las pérdidas ambientales también son relativamente pequeñas.
- Si los datos son demasiado grandes, es necesario fragmentarlos en la capa de red , porque existe un requisito de MTU en la capa de enlace para la transmisión posterior a la capa de enlace.
- Si los datos son demasiado pequeños, menos que el encabezado, entonces la eficiencia de la capa de red se reducirá. Lo que se espera es que un datagrama contenga tanta información de datos como sea posible y la menor información adicional posible en el encabezado.
4. UDP no tiene control de congestión y es adecuado para muchas aplicaciones en tiempo real.
- **Esto no significa que no haya control de congestión. Incluso si la red vuelve a estar congestionada, UDP no ralentizará al remitente y este problema no se controlará en este momento. ¿Crees que este acuerdo no es bueno en esta situación? **En realidad no, debido a que UDP no tiene control de congestión, también trae algunas ventajas, como ser adecuado para muchas aplicaciones en tiempo real, como telefonía IP y videoconferencias, y permite descartar algunos datos cuando ocurre una congestión en la red. ., porque estas aplicaciones en tiempo real no pueden permitir demasiadas demoras en los datos, de hecho, se permite una pequeña pérdida.
- Para situaciones de congestión particularmente graves, se tomarán ciertas medidas correctivas, como la corrección de errores de reenvío o la retransmisión de mensajes perdidos.
5. La sobrecarga del encabezado UDP es pequeña, 8B , mientras que TCP es 20B.
2.2 Formato de encabezado UDP
El número total de campos de encabezado se fija en 8B , incluidos 源端口号, 目的端口号y son todos 2B (16 bits) .UDP长度UDP检验和
16位UDP长度: Se refiere al campo de datos + campo de encabezado. Si el campo de datos es 7B, entonces la longitud UDP es 15.
16位UDP检验和
- Caso 1: compruebe si todo el datagrama UDP tiene errores y deséchelo si los tiene.
- Caso 2: al dividir (cuando el extremo receptor lo recibe, necesita dividirlo en diferentes procesos según el número de puerto), si no se puede encontrar el número de puerto de destino correspondiente, el mensaje se descartará y el "puerto" ICMP se enviará al remitente. Mensaje de error "Inalcanzable".
2.3 Análisis del campo del pseudoencabezado UDP
El pseudo encabezado solo aparece al calcular la suma de verificación y no se envía hacia abajo ni hacia arriba. El pseudoencabezado es el encabezado del datagrama IP simulado.
源IP地址: 4 bytes.目的IP地址: 4 bytes.0: 1 byte, todos 0, es decir, el tercer campo del encabezado está fijo con todos 0.- En el pseudo encabezado
17: 1 byte, el campo de protocolo del encabezado del datagrama IP que encapsula el mensaje UDP es 17 . UDP长度: 2 bytesUDP长度 = UDP首部8B + 数据部分长度(sin incluir el pseudoencabezado)
2.4 Proceso de datagrama de usuario UDP de verificación de pseudoencabezado
¿Cómo utilizar pseudo encabezados para verificar si hay errores en los datagramas de usuario UDP?
Piense en ello como muchas cadenas de 16 bits conectadas entre sí, es decir, muchos componentes de 4 bytes. Como se muestra en la mitad derecha de la figura siguiente, cada cadena de 16 bits se escribe una al lado de la otra como un grupo:
Del lado emisor :
1. Complete el pseudo encabezado.
2. Complete el campo de suma de verificación con todos ceros.
3. Complete la parte de datos con ceros (los datagramas UDP deben considerarse como muchas cadenas 4B concatenadas).
4. Cálculo: Sume las partes del pseudoencabezado + encabezado + datos utilizando el código binario en complemento a uno.
5. Complete el complemento a uno de la suma en el campo de suma de verificación en el encabezado .
6. Elimine el pseudoencabezado y envíelo.
Del lado receptor :
1. Complete el pseudo encabezado.
2. La parte pseudoencabezado + encabezado + datos se suma mediante complemento binario.
- Nota: La suma de verificación en el remitente es todo 0 al calcular la suma , mientras que en el receptor la suma de verificación es la inversión del resultado de la suma anterior. Aquí agregamos la suma de verificación .
3. Si el resultado final es todo 1, no hay error, de lo contrario el datagrama se descartará o la capa de aplicación adjuntará una advertencia de error.
La siguiente diferencia en la suma es la parte de la suma de verificación. En el extremo receptor, esta suma de verificación es la suma de verificación en el extremo emisor y ya no se calcula utilizando todos los 0:
**¿Por qué la suma final es 1? ** Se puede ver que el resultado final obtenido en el extremo del envío es el código inverso y puesto en el extremo de la verificación, luego el valor calculado + el valor del código inverso es todo 1. Agregue las dos líneas siguientes.
3. protocolo TCP
3.1 Características del protocolo TCP y formato de mensaje.
3.1.1 Características del protocolo TCP
1. TCP es un protocolo de capa de transporte orientado a conexión (conexión virtual).
- Conexión virtual: igual que la comunicación lógica de la capa de transporte, no es una conexión física real. La conexión física se refiere a agregar los encabezados de cada capa al datagrama y colocarlo en el enlace para su transmisión, y luego ir al extremo receptor para Decapsulación paso a paso, esta es una conexión física completa. El uso del protocolo TCP es como si los dos procesos hubieran establecido una conexión punto a punto, por lo que es una conexión virtual.
2. Cada conexión TCP solo puede tener dos puertos y cada conexión TCP solo puede ser punto a punto.
3. TCP proporciona servicios de entrega confiables, sin errores, sin pérdidas, sin duplicaciones y con llegada en orden. [Confiable y ordenado, nada perdido ni pesado]
4. TCP proporciona comunicación full-duplex.
- En la comunicación full-duplex, ambos extremos pueden enviar y recibir datos al mismo tiempo.
- Por sus características, ambos extremos de la conexión del protocolo TCP estarán equipados con un búfer de envío (cola lista para enviar) y un búfer de recepción (cola lista para recibir) .
发送缓存: Datos listos para ser enviados y datos enviados pero aún no confirmados. (Para algunos datos que se han enviado pero que aún no han recibido confirmación, no se pueden eliminar directamente del caché, porque una vez que se agota el tiempo de espera, será necesario retransmitirlos)接收缓存: datos que llegan en orden pero que aún no han sido leídos por la aplicación que acepta y datos que llegan fuera de orden. (Para cada dato que llega en orden, solo cuando el orden de los datos está ordenado, el receptor puede sacar los datos uno por uno del búfer de recepción y entregarlos al proceso correspondiente).
5. TCP está orientado a flujos de bytes.
- Se refiere al hecho de que TCP ve los datos entregados por la aplicación como solo una serie de flujos de bytes no estructurados .
流: una secuencia de bytes que fluyen hacia o desde un proceso.
Como se muestra en la siguiente imagen, el archivo contiene varios bytes. Colocamos 10 bytes en el caché y esperamos el envío:
Cuando comienza el envío, primero se pueden tomar 3 bytes para formar un segmento TCP, y luego se agrega el encabezado TCP a este segmento para formar un segmento completo y luego se coloca en el enlace para la transmisión. Para esto, el número de bytes transferidos varía según sobre la situación específica:
Entonces, el protocolo TCP está orientado a bytes o flujo de bytes.
3.1.2 Formato del encabezado del segmento TCP
Descripción general del encabezado del segmento TCP :
- Un segmento de mensaje TCP consta de un encabezado TCP y una parte de datos TCP.
- Se requiere que el número de bits de datos en el encabezado TCP sea un múltiplo entero de 4 B. En este momento, el encabezado TCP debe completarse con algunos datos, generalmente todos 0.
- El encabezado contiene un 20B fijo y otras opciones y campos de relleno se calculan por separado.
La siguiente es una descripción detallada de los 11 campos del encabezado TCP :
①-② 源端口、目的端口: Cada uno ocupa 2B, que son 16 bits.
③ 序号位: Ocupa 4B. Cada byte en el flujo de bytes transmitido en una conexión TCP está numerado en secuencia. Este campo indica el número de secuencia del primer byte de los datos enviados en este segmento.
- En el Ejemplo 1, puede ver que se envían 1, 2 y 3 bytes continuamente, luego el número de secuencia en el encabezado TCP es 1 (el primer byte transmitido), lo que significa el primer byte.
- En el Ejemplo 2, puede ver que se envían 4, 5 y 6 bytes continuamente, por lo que el número de secuencia en el encabezado TCP también es 4 (el primer byte transmitido), que representa el cuarto byte.
④ 确认号: Espere recibir el número de secuencia del primer byte de datos del siguiente segmento de mensaje de la otra parte. Si el número de confirmación es N, demuestra que todos los datos hasta el número de secuencia N - 1 se han recibido correctamente.
- Este número de confirmación se envía a través del host de destino . Cuando llegue el número de bytes 1, 2 y 3 transmitidos por nuestro primer mensaje, el objetivo devolverá un segmento de mensaje de confirmación. En este momento, el encabezado del segmento de mensaje de confirmación contiene un número de confirmación = 4, lo que significa que el problema es que se han recibido los bytes 1, 2 y 3, y ahora espero recibir el byte número 4.
⑤ 数据偏移（首部长度）: ¿A qué distancia está la posición inicial J de los datos en el segmento TCP desde el inicio del segmento TCP, en unidades de bits 4B, es decir, un valor es 4B?
La longitud del segmento TCP se refiere a la siguiente figura:
Dado que la unidad es 4 B, si el desplazamiento de datos es 1111, entonces es 16 x 4 B = 64 B. El encabezado TCP actual es de 64 bytes, fijo en 20 B, y el relleno + opcional es 44 B.
⑥6 bits de control :
紧急位URG: Cuando URG = 1, indica que hay datos urgentes en este segmento de mensaje. Son datos de alta prioridad y deben transmitirse lo antes posible sin hacer cola en el caché. Se utiliza junto con el campo de puntero de emergencia . (De la siguiente manera, cuando se han dividido varios segmentos del mensaje a enviar en el caché, el mensaje en el cuarto segmento en el camino contiene URG = 1, lo que significa que los datos deben transmitirse lo antes posible, y se le da prioridad. En este punto, puedes pasar al frente sin tener que esperar en la fila hasta su turno.)确认位ACK: Cuando ACK = 1, el número de confirmación es válido. Una vez establecida la conexión, todos los segmentos del mensaje transmitido deben tener ACK establecido en 1.推送位PSH: Cuando PSH = 1, el receptor entrega el proceso de solicitud lo antes posible y no espera hasta que se llene el caché antes de entregarlo hacia arriba. (Se refiere a un procesamiento de emergencia realizado por el receptor . Como se muestra en la figura siguiente, si el segundo segmento del área de caché es PSH = 1, se le dará la prioridad de un segmento de mensaje y se entregará rápidamente a la aplicación. capa. proceso.)复位RST: Cuando RST = 1, indica que ocurrió un error grave en la conexión TCP y se debe liberar la conexión y luego restablecer el enlace de transmisión.同步位YSN: Cuando SYN = 1, indica una solicitud de conexión/mensaje de aceptación de enlace. (Como se muestra en la figura siguiente, si el remitente envía SYN = 1, el extremo receptor también devolverá un SYN = 1).终止位FIN: Cuando FIN = 1, indica que los datos del remitente de este segmento se han enviado y es necesario liberar la conexión.
Comprendamos brevemente los exámenes de pulsación y reinicio.
⑦ 窗口字段: Se refiere a la ventana de recepción de la parte que envía este segmento, es decir, la cantidad de datos que la otra parte puede enviar ahora.
- Ejemplo 1: en este momento, el encabezado del segmento de mensaje enviado por el extremo receptor tiene un bit de ventana de 65536. Si el extremo emisor A lo recibe en este momento, establecerá el tamaño de la ventana de su propio búfer de envío en 65536 .
- Ejemplo 2: en este momento, el número de confirmación en el segmento de mensaje enviado por el extremo receptor B es 701 y el campo de la ventana es 1000. En este momento, el remitente configurará su propio búfer de envío en 1000 y enviará su propio 701-1700. bytes al extremo receptor. Cuadrado B.
⑧ 校验和: Verifique el encabezado + datos, agregue un pseudo encabezado 12B al verificar y el cuarto campo (correspondiente al campo de protocolo) es 6.
⑨ 紧急指针: Tiene significado solo cuando URG = 1, lo que indica el número de bytes de datos de emergencia en este segmento.
- Ejemplo: si el puntero de emergencia es 50, significa que la parte de datos TCP desde el 1.er byte hasta el 50.º byte son datos urgentes.
10 选项: Longitud máxima del segmento MSS, expansión de ventana, marca de tiempo, confirmación de selección...
11 填充字段: Si el campo de opción no es un múltiplo entero de 4B, entonces debe completarse con un múltiplo entero de 4B.
3.2 Gestión de conexiones TCP
3.2.1 Tres etapas de transmisión de conexión TCP
Hay tres etapas en la transmisión de una conexión TCP :
La conexión TCP se establece mediante el método cliente / servidor . El proceso de aplicación que inicia activamente el establecimiento de la conexión se llama cliente, y el proceso de aplicación que espera pasivamente el establecimiento de la conexión se llama servidor.
Apretón de manos de tres vías al conectar:
3.2.2 Proceso de establecimiento de conexión TCP
3.2.2.1 Explicación detallada del protocolo de enlace de tres vías para la conexión
ROUND1 : El cliente envía un segmento de solicitud de conexión sin datos de la capa de aplicación.
SYN = 1，seq = x（随机）
- SYN = 1: Es 1 cuando se solicita la conexión.
- seq = x (aleatorio): bit del número de secuencia. Este número de secuencia se genera aleatoriamente y puede comenzar desde cualquier número aleatorio al principio.
- El número de confirmación no es válido aquí porque el cliente no ha recibido suficientes segmentos de mensaje del servidor, por lo que el cliente no sabe qué segmento de mensaje de número de secuencia esperará del servidor a continuación. En este momento, confirma El número no tiene sentido.
Solo hay dos situaciones en las que SYN se establece en 1: una es una solicitud de conexión y la otra es una confirmación de la solicitud de conexión.
RONDA 2 : El servidor asigna caché y variables para la conexión TCP y devuelve un segmento de mensaje de confirmación al cliente , lo que permite la conexión sin datos de la capa de aplicación.
SYN=1，ACK=1，seq=y(随机)，ack=x+1
- SYN=1: La aceptación de la solicitud de conexión sigue siendo 1.
- ACK = 1: cuando ACK = 1, el reconocimiento en minúsculas también es válido en este momento y estos dos deben usarse juntos.
- ack=x+1: en este momento, el número de confirmación debe completarse con el primer byte del segmento de mensaje que se espera que envíe la otra parte. Dado que el número de secuencia solicitado por el cliente la última vez indica que el segmento es x, el siguiente byte que el servidor desea recibir en este momento debe comenzar desde x+1.
- seq = y (aleatorio): en este momento, el segmento del mensaje de confirmación también tiene un byte de número de secuencia, y este número de secuencia también lo asigna aleatoriamente el propio host.
RONDA3 : Después de que el cliente recibe la confirmación del servidor, debe devolver una confirmación para informarle al servidor que hemos establecido una conexión y luego podemos enviarle datos. Lo que se diferencia de los dos primeros segmentos del mensaje es que este tercer mensaje segmento Un segmento de mensaje puede transportar datos, en este momento los datos que se enviarán oficialmente se pueden colocar en el segmento de mensaje.
- El cliente asigna caché y variables para la conexión TCP y devuelve una confirmación confirmada al servidor, que puede transportar datos.
SYN=0，ACK=1，seq=x+1，ack=y+1
- SYN = 0: actualmente no hay ninguna solicitud de conexión o confirmación de la solicitud de conexión, es 0 en este momento. Los datos SYN enviados después de eso son todos 0.
- ACK = 1: cuando ACK = 1, el ACK en minúscula también es válido en este momento y estos dos deben usarse juntos.
- seq = x + 1: El primer byte del segmento que envía es x+1.
- ack = y + 1: Dado que la secuencia anterior quería recibir y, el siguiente número de secuencia que se espera en este momento es y+1.
3.2.2.2 Posibles problemas en el protocolo de enlace de tres vías: ataque de inundación
Para el segundo y tercer paso, tanto el servidor como el cliente asignan caché y variables alrededor del proceso de conexión TCP, lo que causará problemas : 洪泛攻击.
Motivo : problema de ataque de piratas informáticos causado por un protocolo de enlace de tres vías.
Descripción del ataque: El ataque de inundación SYN ocurre en la cuarta capa de OSI. Este método utiliza las características del protocolo TCP, que es un protocolo de enlace de tres vías . El atacante envía TCP SYN. SYN es el primer paquete del protocolo de enlace de tres vías de TCP. Cuando el servidor devuelve ACK, el atacante no lo vuelve a confirmar . Entonces la conexión TCP está en un estado suspendido, que es el llamado La mitad Estado de la conexión . Si el servidor no puede recibir la reconfirmación, enviará repetidamente ACK al atacante, lo que desperdiciará más recursos del servidor.
- En este momento, el atacante aprovecha la situación repetida descrita anteriormente y continúa enviando una gran cantidad de conexiones TCP al servidor. Dado que cada una no puede completar el protocolo de enlace de tres vías, en este momento en el servidor, estas conexiones TCP las conexiones se bloquearán debido a que en este estado, la CPU y la memoria se consumen y, eventualmente, el servidor puede fallar y no puede brindar servicios a los usuarios normales.
Solución al ataque de inundación de sincronización : configurar syn cookie.
3.2.3 Proceso de liberación de conexión TCP (cuatro oleadas)
Salude cuatro veces al cerrar la conexión :
Cualquiera de los dos procesos que participan en una conexión TCP puede terminar la conexión . Una vez completada la conexión, se liberarán los "recursos" (caché y variables) en el host.
ROUND1 : El cliente envía un segmento de liberación de conexión , deja de enviar datos y cierra activamente la conexión TCP.
FIN = 1，seq = u
- FIN = 1: cuando se libera la conexión, el bit final FIN debe establecerse en 1.
- seq = u: se refiere al número de secuencia del primer byte de dicho segmento de mensaje. Dado que este segmento de mensaje generalmente no contiene datos, un número de secuencia puede representar dicho segmento de mensaje.
ROUND2 : El servidor devuelve un segmento de mensaje de confirmación y se libera la conexión del cliente al servidor en esta dirección. (Está en un estado semicerrado en este momento )
ACK = 1，seq = v，ack = u+1
- ACK = 1: el reconocimiento es efectivo en este momento.
- seq = v: Depende de dónde se envió antes, por ejemplo, el último segmento de mensaje enviado por este servidor antes, el último byte es v - 1, y seq está marcado como 1 en este momento.
- ack = u + 1: Indica la confirmación del segmento del mensaje anterior, el mensaje anterior seq = u.
Cuando el anfitrión recibe dicho segmento de mensaje de confirmación, no necesita responder, porque el anfitrión ya ha finalizado la llamada, solo necesita esperar a que el servidor le diga que ha finalizado y luego la conexión entre ellos se establece oficialmente. cerrado.
Nota: Los datos restantes también se enviarán durante este proceso.
RONDA3 : Después de que el servidor envía los datos, envía un segmento de liberación de conexión y cierra activamente la conexión TCP.
FIN = 1，ACK = 1，seq = w，ack = u + 1
- FIN = 1: Siempre que se solicite cerrar la conexión, es necesario iniciar FIN = 1.
- ack = u + 1: dado que esta solicitud se envió directamente después de la fase 2 del servidor cuando se cerró la conexión, el cliente intermedio no envió otra solicitud. En este momento, el campo de respuesta de confirmación sigue siendo u + 1, que es el mismo como en la VUELTA 2. Confirme la visualización.
- seq = v: la situación real también depende de la cantidad de datos enviados por el servidor después de la confirmación de la respuesta después del segundo paso.
ROUND4 : El cliente devuelve un segmento de confirmación y luego espera hasta que el temporizador de espera se establezca en 2MSL (la vida útil más larga del segmento), momento en el que la conexión se cierra por completo.
- 2MSL se refiere a la vida útil del segmento de mensaje más largo. Si el segmento del mensaje de confirmación no llega al servidor, entonces el servidor reenviará la solicitud de cierre de conexión si no la recibe en este momento. Si la solicitud de cierre de conexión se recibe dentro de 2MSL, reiniciará la confirmación.
ACK=1，seq = u + 1，ack = w + 1
3.3 Transmisión confiable TCP
Cuatro mecanismos TCP para lograr una transmisión confiable
Método 1: verificación
Proceso : Igual que la verificación UDP, agregando un pseudo encabezado .
- El método de verificación del protocolo UDP es el mismo que agregar un encabezado al remitente y al receptor, y luego usar el método de cálculo de la suma del complemento binario para determinar si se ha producido un error.
Método 2: mecanismo de número de serie
Al igual que UDP, el segmento de mensaje finalmente enviado puede tener unos pocos bytes en el caché TCP a continuación, luego el número de secuencia indica la posición del primer byte de cada segmento en todo el caché TCP:
Método 3: mecanismo de confirmación (basado en el mecanismo del número de serie)
A continuación podemos ver que cuando el primer segmento del mensaje en nuestra caché TCP se envía al servidor, el primer segmento no se elimina de la caché TCP:
El motivo es esperar la confirmación del servidor antes de eliminarlo . Si no se recibe el mensaje de confirmación, el mensaje puede perderse. Por lo tanto, ¿cómo sabe el remitente que el receptor ha recibido correcta y completamente el mensaje completo?, confiando en Nuestro mecanismo de confirmación, después de que el receptor recibe este segmento de mensaje, devolverá un segmento de mensaje de confirmación.
Se puede ver que cuando nuestro servidor devuelve el mensaje de confirmación, el campo del número de confirmación es 4, lo que significa que se han recibido los datos anteriores a 4. En este momento, el remitente puede eliminar el primer segmento en la caché TCP :
Luego, si hay segmentos 1, 2 y 3, el segundo segmento en el medio todavía está retrasado (puede haberse perdido) y se han recibido los segmentos 1 y 3. En este momento, TCP utilizará la confirmación acumulativa de forma predeterminada. esta vez, el número de confirmación El campo sigue siendo 4, es decir, el servidor le dice al cliente que aún recibiré el mensaje que comienza con el cuarto byte:
- Aunque se dice que se recibe secuencialmente, en este caso el segundo segmento del medio no ha llegado y también se puede recibir el tercer segmento.
En este momento, el cliente enviará el segundo segmento del mensaje, es decir, 4, 5 y 6. Cuando se envía el informe del segundo segmento al servidor, el servidor ha recibido los segmentos 1, 2 y 3. Luego, el la próxima vez El campo del número de confirmación en el segmento de confirmación de envío es 9.
Descripción de la situación de llegar al servidor en orden o fuera de servicio :
- Los segmentos del mensaje llegan completamente en secuencia: en este momento, el receptor devolverá esta confirmación para indicarle al remitente qué segmento del mensaje enviar a continuación (el orden llega al último bit al final del último segmento del mensaje).
- Los segmentos del mensaje no llegan en orden: luego el receptor devolverá un segmento de mensaje de confirmación, en este momento este segmento de mensaje puede indicar qué mensaje debe retransmitir el remitente (el primer segmento de mensaje que no ha llegado en el medio El primero) .
Método 4: retransmisión (tiempo de ida y vuelta promedio ponderado RTTS, mecanismo de retransmisión rápida)
Los mecanismos de reconocimiento y retransmisión no están separados, si el remitente TCP no recibe el reconocimiento dentro del tiempo especificado (tiempo de retransmisión), retransmitirá el segmento del mensaje enviado. [ Retransmisión de tiempo de espera ]
Pregunta 1: ¿Cuándo se retransmitirá?
- Si el remitente no ha recibido la confirmación del receptor después de un cierto período de tiempo, entonces el remitente sabe que el segmento que envió debe perderse y en este momento debe eliminar su segmento del caché, sacarlo y retransmitirlo.
Pregunta 2: ¿Cómo calcular el tiempo de retransmisión?
- Dado que la capa inferior de TCP es un entorno de Internet, los paquetes enviados pueden pasar por la LAN de la autopista o por la red de baja velocidad, entonces la ruta elegida por cada datagrama IP también es diferente, dependiendo del momento. Causa que muchos segmentos de mensajes enviados por el remitente tomen rutas diferentes, por lo que no podemos establecer una hora fija.
- Principio: TCP utiliza un algoritmo adaptativo para cambiar dinámicamente el tiempo de retransmisión. Luego se llama este tiempo de retransmisión
RTTs（加权平均往返时间）, es decir, cuando enviamos el primer segmento de mensaje, los RTT se refieren al primer mensaje obtenido. RTT (la confirmación se conoce desde el momento en que se envía el primer mensaje), y luego, cuando se envía el segundo RTT, también habrá un RTT, y luego, basándose en el primer y segundo RTT, se puede calcular un RTT como el tiempo de paso pesado actual. Al enviar el enésimo segmento de RTT en el futuro, se establecerá y calculará un tiempo promedio ponderado de ida y vuelta mediante una fórmula .
Pregunta 3: Para la retransmisión por tiempo de espera, si no se ha alcanzado el período de tiempo de espera, seguirá esperando. ¿Hay alguna manera de saber si el remitente ha perdido el segmento antes de que ocurra el evento de tiempo de espera y luego lo antes posible? retransmisión?
Solución : 冗余ACK（冗余确认）, relacionado con el mecanismo de confirmación.
Proceso : cada vez que llega un segmento de mensaje de tiempo mayor que el número de secuencia esperado, se envía un ACK redundante para indicar el número de secuencia del siguiente byte esperado.
Para la siguiente situación, puede probar el pedido porque 2 no se recibe después del segmento 1. En este momento, 3, 4 y 5 llegan continuamente. En este momento, el servidor los recibirá. Cuando se recibe un segmento de mensaje, En realidad se enviará. Para un número de confirmación, puede ver que después del segmento 1, dado que el segmento 2 no ha llegado, el número de confirmación en el segmento del mensaje de confirmación es siempre 2. Puede ver que el número de confirmación continua en este momento es los 2 segmentos del medio, por lo que es una confirmación de redundancia . Cuando el extremo receptor recibe tres segmentos con el mismo número de secuencia (tres segmentos consecutivos después del número de secuencia 2 basado en 1), determinará que el segmento No. 2 que envió se ha perdido y será retransmitido (en este momento, el primero Se logra el efecto de retransmisión )
-
**¿Por qué puede llegar desordenado? ** En TCP, el extremo receptor no recibe un mecanismo de confirmación para enviar un segmento de mensaje, puede enviar varios segmentos de mensaje continuamente.
Esta tecnología también puede convertirse en: tecnología de retransmisión rápida .
3.4 Control de flujo TCP
3.4.1 Razones para el control de flujo TCP y el proceso de ventana deslizante
Motivo : al enviar datos, normalmente esperamos que la velocidad de envío de datos sea más rápida, pero si la velocidad de envío es demasiado rápida, es posible que el receptor no tenga tiempo de recibirlos, lo que provocará una pérdida de paquetes muy grave . En este momento, se necesita control de flujo para controlar la tasa de envío del remitente.
Control de flujo : Deje que el remitente disminuya la velocidad para que el receptor tenga tiempo de recibir.
TCP se utiliza 滑动窗口机制para implementar el control de flujo.
Proceso de ventana deslizante : Durante el proceso de comunicación, el receptor ajusta dinámicamente el tamaño de la ventana de envío del remitente, es decir, la ventana de recepción rwnd (el receptor confirma el campo de la ventana del segmento del mensaje para notificar al remitente sobre rwnd) de acuerdo con el tamaño de su propio buffer de recepción. , la ventana de envío del remitente toma el valor mínimo de la ventana de recepción rwnd y la ventana de congestión cwnd .
- Congestión de recursos: la red está bloqueada, lo que significa que la red estaba usando recursos de red en ese momento y había demasiados hosts con recursos de red, lo que causó problemas como envío/reenvío lento y tiempo de cola en toda la red.
- La ventana de envío del remitente depende del mínimo de la ventana de recepción y de la ventana de congestión . [Ventana de envío = Min{ventana de recepción, ventana de congestión}]
La ventana para el remitente se puede cambiar dinámicamente . Esto depende de un segmento de mensaje devuelto por el receptor, que puede ser un mensaje de confirmación o un mensaje de datos. Si el campo de la ventana es grande, significa que el remitente ahora puede enviar más. Para algunos datos, si el campo de la ventana es relativamente pequeño, entonces el remitente enviará menos datos:
- Como se muestra en la figura siguiente, el mensaje de confirmación se recibe y se devuelve uno por uno, en el que la ventana de envío se establece en 6. En este momento, el remitente divide 6 ventanas para enviar a la vez.
3.4.2 Proceso detallado de control de flujo TCP
A envía datos a B. Cuando se establece la conexión, B le dice a A: "Mi rwnd = 400 (bytes)". Suponga que cada segmento de mensaje es 100B y el valor inicial del número de secuencia del segmento de mensaje es 1.
Descripción detallada del proceso :
1. Primero, A solicita a B que establezca una conexión y luego B devuelve un segmento de mensaje de confirmación en el que se establece el campo rwnd = 400 (bytes).
2. El host A recibe el segmento del mensaje de confirmación y lee rwnd = 400. En este momento, divide 400 bytes en su propia ventana del búfer de envío (dado que el segmento del mensaje es 100B, son exactamente 4 segmentos).
Luego se envían 4 segmentos de mensaje continuamente de acuerdo con el tamaño de la ventana, cada segmento tiene 100 bytes. Según la figura, puede ver que los dos primeros segmentos de mensaje son recibidos exitosamente por el host B, pero el tercer segmento se pierde :
3. En este momento, el host B envía un segmento de mensaje de confirmación, lo que indica que recibiré un segmento de mensaje a partir de 201 bytes, y en este momento también indica que la ventana actual que se puede recibir es de 300 bytes.
La ventana de envío del host A comienza desde 201 bytes que no han sido recibidos por el extremo receptor hasta 500 bytes:
4. En este momento, la ventana de envío del remitente es de 300 bytes y, dado que el segmento de mensaje de 201-300 bytes aún no ha recibido el mensaje de confirmación, permanecerá en la ventana de envío en este momento. A continuación, el host A envía datos. Puede enviar los datos en estas dos cuadrículas a partir de 301, el párrafo 3 y el párrafo 4. En este momento, no se pueden enviar y la ventana solo se puede abrir hasta un máximo de 500 bytes.
5. En este momento, el segmento de mensaje de la ventana de 201-300 bytes ha estado estancado, esperando la confirmación del receptor. Una vez transcurrido el tiempo de espera para el segmento de mensaje de 201-300 bytes, se realizará una retransmisión.
6. El host B puede recibirlo con éxito. En este momento, el host B envía un mensaje de respuesta. El mensaje de respuesta indica que el segmento de mensaje que el host B desea recibir ahora comienza desde 501 y el tamaño de la ventana de envío se puede limitar a 100.
7. El host A comienza a enviar un segmento que comienza en 501 bytes. Dado que el tamaño de la ventana es de solo 100 bytes, no puede continuar enviando después de enviar este segmento.
8. En este momento, el host B receptor devuelve un segmento de mensaje de confirmación, que indica que quiere comenzar desde 601 bytes y que el tamaño de la ventana de envío es 0.
Dado que la ventana está configurada en 0, el remitente no puede enviar datos en este momento.
Pregunta adicional 1: si el host A ha estado esperando que el host B envíe una notificación de ventana distinta de cero y el host B envía un nuevo segmento (el tamaño de ventana permitido es 400) y se pierde durante la transmisión, si no hay ninguna medida en Esta vez, el Host A y el Host B siempre se esperarán el uno al otro. Esta situación de esperarse mutuamente es similar a un punto muerto. Entonces, ¿cómo resolverlo?
Solución : TCP establece un temporizador continuo para cada conexión. Siempre que una de las partes de la conexión TCP reciba la notificación de ventana cero de la otra parte, se iniciará este temporizador continuo . Si el temporizador expira, el host A enviará un segmento de mensaje de detección y el host B retransmitirá el mensaje de notificación.
- Si la ventana del mensaje de notificación retransmitido sigue siendo 0, entonces el host A restablecerá un temporizador continuo. En este momento, si todavía no hay un mensaje de confirmación de notificación antes de que expire el temporizador, entonces el host A enviará otro mensaje de detección. el host B lo retransmite nuevamente.
3.5 Control de congestión TCP
3.5.2 Comprender el control de congestión y su diferencia con el control de flujo
¿Qué es el control de la congestión?
- El estado de la red no es bueno y la red está bloqueada, lo que hace que toda la velocidad de recepción y envío de datos se reduzca.
Condiciones de congestión : suma de demandas de recursos > recursos disponibles
- Los recursos se refieren a: cierta capacidad de enlace en la red, como el ancho de banda, 50 M de ancho de banda en un enlace, muchas personas envían datos a través de este enlace, lo que resulta en un ancho de banda insuficiente en este enlace para estas personas, entonces en este momento Esto causará congestión en La red Al mismo tiempo, el caché en el nodo de conmutación y el procesador en el nodo de conmutación , como el procesador en el enrutador, son todos recursos .
Si la demanda total de un determinado recurso en la red excede la parte disponible de este recurso durante un cierto período de tiempo, el rendimiento de la red cambiará naturalmente. En este momento, muchos recursos serán insuficientes al mismo tiempo, lo que resultará en las siguientes situaciones:
- Hay muchos recursos en la red que no están suficientemente aprovisionados al mismo tiempo -> el rendimiento de la red se deteriora -> el rendimiento de la red disminuirá a medida que aumenta la carga de entrada.
Función de control de congestión : evita que se inyecten datos excesivos en la red.
- Al coordinar la coordinación entre todos los hosts que utilizan este recurso de red, se puede evitar que se inyecten datos excesivos en la red y se puede aliviar la congestión de la red.
La diferencia entre control de congestión y control de flujo :
拥塞控制: Si la parte superior de la figura siguiente es el receptor y la parte inferior de la figura es el remitente, ambos necesitan enviar datos al receptor, ya que utilizan los recursos de esta red al mismo tiempo y la misma conmutación. nodo, entonces este enrutador hará que esta red esté muy ocupada e incluso puede haber una situación de congestión. El receptor no sabe qué host o hosts están causando esta situación de congestión. La velocidad de envío es demasiado rápida.
流量控制: Es una especie de control de tráfico entre punto a punto, y es un problema de extremo a extremo. Si los datos recibidos por el receptor llegan demasiado tarde para recibirlos, lo será hasta que el remitente los reciba.
Resumen : El control de flujo es un problema punto a punto . La velocidad del remitente es demasiado rápida, lo que provoca un almacenamiento en búfer insuficiente en el receptor. El control de congestión es un problema global , principalmente porque la red está bloqueada .
3.5.3 Cuatro algoritmos para el control de la congestión
3.5.3.1 Comprender los cuatro algoritmos de control de congestión
Cuatro algoritmos : inicio lento, evitación de congestión, retransmisión rápida y recuperación rápida.
Los cuatro anteriores se usan en combinación entre sí en una situación, uno es 慢开始+拥塞避免y la otra combinación es 快重传+快恢复:
Antes de aprender el algoritmo anterior, haga algunas suposiciones:
1. Los datos se transmiten en una dirección, mientras que en la otra dirección sólo se transmiten segmentos de acuse de recibo (para una confirmación paralela se transmiten datos no válidos).
- En la práctica, la confirmación a cuestas también es relativamente común.
2. El receptor siempre tiene suficiente espacio en el buffer, por lo que el tamaño de la ventana de envío depende del grado de congestión.
发送窗口 = Min(接受窗口rwnd，拥塞窗口cwnd)
- Ventana de recepción: el receptor establece el valor de acuerdo con el caché de aceptación e informa a la otra parte que refleje la capacidad del receptor.
- Ventana de congestión: el valor de la ventana establecido por el remitente en función de su propia estimación de congestión de la red, que refleja la capacidad actual de la red.
3.5.3.2 Combinación 1: Arranque lento y prevención de congestión
Comprender el significado de la ventana de congestión y las rondas de transmisión.
- En el examen de ingreso de posgrado, se debe tener claro el proceso de solicitud del Algoritmo Ade y no examinar los detalles específicos de los cuatro algoritmos.
La ordenada se refiere al 拥塞窗口cwndvalor inicial de 1, que representa un segmento de mensaje y una longitud máxima de segmento de mensaje MSS (en este momento, 4 en la figura se refiere a 4 MSS y 8 se refiere a 8 MSS). Como el número de rondas de transmisión aumenta, la ventana de congestión cambia.
La abscisa se refiere a 传输轮次una ronda de transmisión como una unidad, que se refiere al tiempo que lleva enviar un lote de segmentos de mensajes y recibir su confirmación.
- Una ronda de transmisión: el momento en que se envía un lote de segmentos de mensajes y se recibe su acuse de recibo, un RTT de retardo de ida y vuelta. El tiempo desde que se comienza a enviar un lote de segmentos de mensajes dentro de la ventana de congestión hasta que se comienza a enviar el siguiente lote de segmentos de mensajes dentro de la ventana de congestión.
Comprensión de las rondas de transmisión :
De la siguiente manera: el Host A envía un segmento de mensaje al Host B. En este momento, el Host B responde con un segmento de mensaje al Host A. Esto se cuenta como una ronda.
Dado que la condición de la red es muy buena, en este momento se enviarán varios segmentos de mensajes más m2 y m3. En este momento, el host B devolverá dos confirmaciones en secuencia después de recibir los dos segmentos de mensajes. En este caso, hasta que M3 confirme, entonces El tramo es la segunda ronda de transmisión.
En este momento, la ventana de envío aumenta nuevamente. En este momento, la ventana es 4. Luego se pueden enviar 4 segmentos de mensaje continuamente en este momento. Cuando el cuarto segmento de mensaje se recibe en secuencia, se considera como la tercera ronda de transmisión. :
Proceso detallado de inicio lento y prevención de congestión
Un comienzo lento se refiere a un crecimiento exponencial, un proceso de crecimiento explosivo.
- La razón principal de la lentitud es que solo se inyecta un mensaje al principio, lo que será mucho más lento para la inyección inicial de muchos segmentos de mensaje.
Proceso : Primero, realice una prueba en esta red para ver la situación de congestión de esta red. Si es mejor, aumente mi ventana de congestión del remitente y aumente la ventana de congestión. Este múltiplo es 2 veces y se divide en cuatro etapas.
①Al principio, se realiza **【Inicio lento】La primera ronda de transmisión es 1 MSS, la segunda ronda de transmisión es 2 MSS, la tercera ronda de transmisión es 4 MSS y la cuarta ronda de transmisión es 16 MSS. En este momento , puede ver que se ha alcanzado el valor inicial de ssthresh 16, que se refiere a un umbral de inicio lento**.
②En este momento, comenzará desde lento hasta **[Evitar congestión]**, porque actualmente hay más segmentos de mensajes inyectados y le preocupará que se produzca congestión pronto, por lo que reducirá ligeramente la velocidad. En este momento, según la ventana de congestión anterior, se agregará una ventana de congestión cada vez. Puede ver que es +1 cada vez desde 5 rondas hasta 12 rondas, y en este momento llega a 24 MSS.
- Umbral de inicio lento: una vez que se alcanza el valor inicial del umbral de inicio lento, la velocidad se reducirá ligeramente y el inicio lento se ingresará para evitar la congestión.
- Proceso de evitación de congestión: es un proceso de crecimiento lineal, +1 cada vez según el umbral de inicio lento.
③ Dado que cuando se alcanza 24MSS, la red está congestionada y se pierden paquetes, en este momento volverá a ingresar al **[Estado de inicio lento]**, la ventana de congestión volverá a 1 y el número de segmentos aumentará de 24 a 24 en un instante, se reduce a 1 segmento de mensaje y el proceso posterior es continuar ejecutando el inicio lento, 1, 2, 4, 8, y luego en la ronda 17, tenga en cuenta que el valor umbral en este momento cambia a 12.
- **¿Cómo se determina el nuevo umbral? ** De acuerdo con la situación actual de congestión de la red, una vez que ocurre la congestión de la red, la ventana de congestión / 2 se reducirá inmediatamente. Dado que la ventana de congestión de la congestión de la red anterior era 24, entonces 24/2 = 12 en este momento, entonces esto El umbral actual es 12.
④Al ingresar al estado ** [Evitar congestión] **, seguirá aumentando linealmente, +1 cada vez, y el proceso posterior será el mismo. Una vez que se produzca la congestión de la red, se establecerá un nuevo umbral y volverá a Inicio lento.
3.5.3.3 Combinación 2: Retransmisión rápida y recuperación rápida
El motivo de la aparición de la retransmisión rápida es principalmente para resolver el problema del tiempo de espera demasiado largo. El proceso del mecanismo es el siguiente :
- En este momento, se envían continuamente cinco segmentos de mensaje M1, 2, 3, 4 y 5. Cuando se envía M1 a B, se devolverá un número de confirmación, donde ack = 2, lo que indica que se recibirá el segundo mensaje. , el mensaje 2 se pierde y luego B recibe los segmentos del mensaje de confirmación de M3, 4 y 5, donde ack = 2, luego hay un total de cuatro segmentos del mensaje de confirmación con ack = 2. Basado en los últimos tres Lo mismo ack=2 se llamará reconocimiento redundante . En este momento, el host A reenviará el mensaje M2 .
**¿Cómo se refleja la recuperación rápida? **Puedes ver en la figura siguiente que cuando la ventana de congestión es 24 a 12 veces, debido a que se ejecuta [retransmisión rápida] después de recibir 3 confirmaciones duplicadas, entrará en [estado de recuperación rápida]. En este momento no es necesario para reducir la ventana de congestión a 1MSS. En este momento, caerá a un nuevo valor de umbral. En este momento, en esta etapa de 12 valores de umbral, realizamos [evitar la congestión] y realizamos una suma lineal para aumentar.
- **¿Cómo se determina el umbral? **Aquí es cuando se producirá una confirmación duplicada. Configure la ventana de congestión en este momento en 24/2=12 y luego realizaremos una recuperación rápida.
**¿Qué es la recuperación rápida? ** No es necesario reducirlo a 1, sino reducirlo directamente al nuevo valor de umbral (ventana de congestión donde se produce la retransmisión rápida/2) y luego utilizar el algoritmo para evitar la congestión.
La versión TCP-Tahoe en la figura ha sido abandonada, esta versión debería ser cuando ocurre una retransmisión rápida, en este momento la ventana de congestión cambia directamente a la fase inicial 1 de inicio lento, y luego se ejecuta la estrategia correspondiente.
Organizador: Largo Camino Duración: 2023.8.7-8