Capa de transporte TCP y UDP

Capa de transporte: responsable de la capacidad de los datos para ser transmitidos desde el emisor al receptor,proceso a procesoComunicación

Hablemos de los números de puerto

El número de puerto identifica un proceso específico en la capa de aplicación, solo con el número de puerto se puede identificar el proceso específico entregado por la capa de transporte.

En el protocolo TCP/IP, se utiliza una tupla de cinco como "IP de origen", "número de puerto de origen", "IP de destino", "número de puerto de destino", "número de protocolo" para identificar una

división de rango de número de puerto de comunicación:

0 - 1023: números de puerto conocidos, HTTP, FTP, SSH y otros protocolos de capa de aplicación ampliamente utilizados, todos sus números de puerto son fijos
1024 - 65535: el número de puerto asignado dinámicamente por el sistema operativo El número de puerto del programa cliente , es asignado por el sistema operativo de este rango

Cuando escribimos un programa para usar números de puerto, debemos evitar estos números de puerto conocidos

comando pidof

Sintaxis: pidof [nombre del proceso]
Función: Buscar el pid del proceso según el nombre del proceso

UDP

①Formato del lado del protocolo UDP

Longitud UDP de 16 bits: indica la longitud de todo el datagrama (encabezado UDP + datos UDP)
Suma de comprobación de 16 bits: comprueba si los datos del mensaje recibido son coherentes con lo que se envió; si la suma de comprobación es incorrecta, se descartará directamente

Cómo UDP garantiza la separación de encabezado y
carga útil

¿Cómo decide UDP qué protocolo entregar su carga útil a la capa superior?
A través del número de puerto de destino de 16 bits, el proceso de destino está vinculado al número de puerto y, a través de él, descubrirá
cómo la capa de transporte del protocolo de la capa superior encuentra el servicio correspondiente a través del proceso portuario?
A través de la tabla hash asignada directamente, se abre una matriz de tamaño 65536 y la matriz almacena el pid vinculado al puerto

Comprensión de los encabezados:

②Características de UDP

1. Siempre que se reciban los datos enviados desde la capa de aplicación, no importa si el extremo del par puede comunicarse o no, y no hay un búfer de envío, e inmediatamente los envía a la red tal como están.
2. El proceso de la transmisión UDP es similar a enviar una carta, UDP simplemente la envía, en cuanto a la otra parte, no me importa si la recibo o no
. 3. Sin conexión: conozco la IP y el número de puerto del par y transmito directamente sin establecer una conexión
4. No confiable: no hay mecanismo de confirmación ni mecanismo de retransmisión, si el segmento no se puede enviar debido a una falla en la red Por otro lado, la capa del protocolo UDP no devolverá ninguna información de error a la aplicación 5. Orientado a datagramas: el número y la cantidad de datos de lectura y escritura no se pueden controlar de manera flexible.La capa
de aplicación envía el mensaje a UDP, y UDP lo envía tal como está, no solo no se dividirá ni se fusionará

Para una comprensión orientada a datagramas:
si se usa UDP para transmitir 100 bytes de datos: el remitente llama a sendto una vez y envía 100 bytes, luego el receptor también debe llamar al recvfrom correspondiente una vez, leerlo una vez y recibir 100 bytes; en lugar de llamar recvfrom 10 veces en un bucle, cada una de las cuales recibe 10 bytes

③ Búfer UDP

UDP no tiene un búfer de envío real. Llamar a sendto se transferirá directamente al kernel, y el kernel pasará directamente los datos al protocolo de capa de red para las acciones de transmisión posteriores.

UDP tiene un búfer de recepción, que puede guardar temporalmente los paquetes que llegan, pero este búfer de recepción no puede garantizar que el orden de los paquetes UDP recibidos sea el mismo que el orden de los paquetes UDP enviados. Si el búfer está lleno, los datos UDP entrantes será tirado

④Precauciones para usar UDP

Hay una longitud máxima de 16 bits en la cabecera del protocolo UDP, es decir, la longitud máxima de datos que puede transmitir un UDP es de 64K (incluida la cabecera UDP),
si los datos que necesitamos transmitir superan los 64K, necesitamos paraSubcontratación manual en la capa de aplicación, enviado varias veces y ensamblado manualmente en el extremo receptor

TCP

TCP es un protocolo confiable. Para garantizar la confiabilidad, TCP procesa más y la eficiencia se reducirá
. UDP no garantiza la confiabilidad, por lo que es más simple y rápido.

Formato de segmento de protocolo TCP

Número de serie: la posición inicial de los datos enviados, generada aleatoriamente por la computadora
. Número de serie de confirmación: indica el número de serie inicial del mensaje que debe enviarse la próxima vez e informa a la otra parte que todos los bytes antes del número de serie de confirmación han sido enviados. Longitud
del encabezado TCP: Indica la longitud del encabezado TCP Longitud, la unidad es de cuatro bytes, por lo que la longitud máxima del encabezado TCP es 15 * 4 = 60, incluidas las opciones, y la mínima es el encabezado estándar de 20 bytes.
Reservado: indicadores de seis bits para campos que no se han utilizado
: se utilizan para distinguir diferentes SYN : indica número de confirmación es válido:
el establecimiento de la conexión RST cuando no llega: Hay un problema con la conexión entre las dos partes, y la otra parte solicita restablecer la conexión URG: Si el puntero de emergencia es válido, si es válido , será Ver el puntero urgente para leer esta parte de los datos primer puntero urgente de 16 bits: el desplazamiento de los datos urgentes en el mensaje, qué parte de los datos son datos urgentes y cuántos datos leer está determinado por la descripción del campo de opción

Para RST:

De hecho, si una de las partes se desconecta anormalmente en el medio, cuando recibe un mensaje de la otra parte, enviará RST a la otra parte, indicando que la otra parte cree que la conexión todavía está allí, pero se ha desconectado. y solicitudes para restablecer la conexión.

Cómo se separan el encabezado y la carga útil: a través del campo de longitud del encabezado de 4 bits

TCP no solo garantiza la confiabilidad, sino que también implementa medidas para mejorar la eficiencia de la transmisión

fiabilidad

La confiabilidad de TCP incluye dos aspectos: por un lado, se refleja en el encabezado y, por otro lado, se refleja en la lógica del código de tcp.

①Suma de comprobación

Verifique todo el mensaje, si hay un error, se descartará directamente

②Mecanismo de reconocimiento de reconocimiento (ACK)

En términos generales, si el mensaje que enviamos recibe una respuesta, entonces se puede considerar que el mensaje es recibido de manera confiable por la otra parte, que es el mecanismo de respuesta de confirmación.

Si el acuse de recibo no se recibe dentro de un período de tiempo, el remitente puede considerar que los datos se han perdido y retransmitir, de modo que incluso si el paquete se pierde, se puede garantizar que los datos lleguen a la otra parte para una transmisión confiable.

③Número de serie

Cada byte de datos enviados por TCP está numerado, es decir, el número de secuencia

El número de serie identifica si se han recibido los datos

. Cada ACK tiene un número de serie de confirmación correspondiente, lo que significa que le indica al remitente que se ha recibido el número de serie anterior. La próxima vez, comience a enviar desde aquí.

El número de secuencia para llegar al
TCP en secuencia está orientado al flujo de bytes, y el orden en que los mensajes enviados llegan al búfer del receptor es impredecible, entonces, ¿cómo garantizar el orden de los mensajes en el búfer de recepción
? mensajes, a través del número de secuencia de 32 bits, los paquetes se reorganizan en la capa de transporte de acuerdo con el número de secuencia y se colocan en el búfer de recepción, asegurando así que el orden de envío sea consistente con el orden de recepción

Deduplicación del número de secuencia:
si se recibe un mensaje con el mismo número de secuencia, el extremo receptor descartará directamente el mensaje para lograr el efecto de la deduplicación

¿Por qué necesita dos conjuntos de números de serie?
TCP es full-duplex, ambas partes pueden enviar datos al mismo tiempo y ambas partes deben confirmar el mecanismo de respuesta, por lo que se requieren dos conjuntos de números de serie, uno es el número de serie de los datos enviados por sí mismo y el otro es el número de serie de los datos recibidos.

④Mecanismo de retransmisión de tiempo de espera

Como se mencionó anteriormente, la base para interpretar si los datos enviados por usted son recibidos es si se recibe una respuesta, si no se recibe después de un cierto período de tiempo, se retransmitirá.

Solo hay dos razones para no recibirlo Se pierde el mensaje de envío o se pierde el mensaje de respuesta
Caso 1: Se pierde el mensaje de envío.

Situación 2: Pérdida del paquete de respuesta
Cuando se recibe un paquete duplicado, el paquete duplicado se determinará de acuerdo con el número de secuencia y el paquete enviado se descartará directamente.

Entonces, ¿cómo determinar el tiempo de espera? El
tiempo de espera se controla en una unidad de 500 ms, y el tiempo de espera para cada retransmisión de tiempo de espera es un múltiplo entero de 500 ms.

Si aún no hay respuesta después de reenviar una vez, espere 2*500ms antes de retransmitir, si aún no hay respuesta, espere 4*500ms para retransmitir, y así sucesivamente, aumentando exponencialmente.

Después de acumular una cierta cantidad de retransmisiones, TCP considera que la red o el host del mismo nivel es anormal, detiene la retransmisión, cierra la conexión a la fuerza y ​​notifica a la aplicación que la comunicación es anormal y se cancela a la fuerza.

⑤Control de flujo

Proceso de envío de datos:

El control de flujo resuelve el problema de pérdida de paquetes causado por el hecho de que los datos del remitente son demasiado rápidos y el receptor llega demasiado tarde para recibirlos, es decir,Coordinar el envío de datos y las capacidades de recepción.

Después de que el remitente reciba esta ventana, reducirá la velocidad de envío al deslizar la ventana.

Entonces, ¿cómo sabe el tamaño de la ventana del extremo del par cuando envía datos por primera vez?
El tamaño de la ventana se negocia durante el protocolo de enlace de tres vías

Entonces, el tamaño de la ventana en el mensaje se refiere al tamaño del espacio restante en su propio búfer de recepción.

Ajuste la velocidad de envío de datos al recibir el tamaño de la ventana de la otra parte, para lograr el propósito del control de flujo

⑥Gestión de conexiones

En circunstancias normales, TCP necesita pasar por un protocolo de enlace de tres vías para establecer una conexión y agitar cuatro veces para desconectar la
conexión

.

Estado TIME_WAIT

El protocolo TCP estipula que la parte que cierra activamente la conexión debe estar en el estado TIME_WAIT y esperar dos veces MSL (vida útil máxima del segmento) antes de que pueda alcanzar el estado CERRADO.

Por lo tanto, en el estado TIME_WAIT, el cliente no ha liberado una conexión limpia y el número de puerto aún está ocupado, lo que hace que sea imposible vincular el número de puerto.

Entonces, ¿cómo resolver este problema de falla vinculante?
Después de crear el socket de escucha, use setsockopt() para establecer el descriptor de socket. La opción SO_REUSEADDR es 1, lo que significa que se permite crear múltiples descriptores de socket con el mismo número de puerto pero diferentes direcciones IP.

⑦Control de congestión

En cuanto al control de flujo anterior, solo consideraron la situación de los hosts de doble extremo y no consideraron el estado de la red.
Aunque la congestión de la red no se puede resolver bien, no puede aumentar la situación de congestión y esperar la recuperación de la situación. lo que es equivalente a reducir los atascos de tráfico.Los vehículos ingresan al área congestionada para aliviar la congestión.La congestión
de la red afecta a los hosts en toda la red, todos los hosts son responsables, y no solo un solo host implementa el control de congestión.Una
pequeña cantidad de pérdida de paquetes, solo nosotros creo que está provocando una retransmisión de tiempo de espera; una gran cantidad de pérdida de paquetes, creemos que la red está congestionada

Para limitar la cantidad de datos enviados al remitente, se introduce el concepto de ventana de congestión: la
ventana de congestión es un valor numérico, lo que significa que los datos enviados en un momento son más grandes que la ventana de congestión, lo que puede causar congestión en la red. problemas.

Cada host tiene un tamaño de ventana de congestión, y el tamaño de la ventana de congestión cambia dinámicamente, y la ventana de congestión de diferentes hosts puede ser diferente

Ventana deslizante VS ventana de paquetes TCP VS ventana de congestión

ventana deslizante	Representa el tamaño de la capacidad de envío, igual a min (tamaño de ventana TCP, tamaño de ventana de congestión propia)
Tamaño de la ventana TCP	Representa el tamaño de la capacidad de recepción del remitente TCP (espacio restante en el búfer de recepción)
ventana de congestión	Valor numérico que representa la posible congestión de la red

A continuación se explica cómo resolver un solo host:

TCP introduce un mecanismo de inicio lento:
primero envíe una pequeña cantidad de datos, explore la ruta, descubra el estado actual de congestión de la red y luego restablezca lentamente la comunicación
.

¿Por qué restaurar a 1 y luego realizar un crecimiento exponencial?
1. Es necesario confirmar si la red todavía tiene pérdida de paquetes incluso cuando solo hay una pequeña cantidad de datos.
2. En la etapa inicial del crecimiento exponencial, se puede probar con mayor precisión y luego se puede determinar el estado de la comunicación. restaurado rápidamente en forma exponencial.

Sin embargo, durante la recuperación, el crecimiento exponencial es demasiado rápido. Si es más grande que el tamaño de la ventana de recepción de la otra parte, el significado de la ventana de congestión se perderá. Por lo tanto, establezca un umbral para un inicio lento y si el Si se

supera el umbral, utilice el crecimiento lineal en su lugar.

Mejorar el rendimiento

①Ventana deslizante y retransmisión rápida

Si utiliza el mecanismo de respuesta de reconocimiento del que acabamos de hablar, el segmento de datos se envía en serie uno por uno, lo que es muy ineficiente.

Entonces, ¿por qué el remitente no envía todos los datos a la vez?
Cuando el remitente envía datos, no solo se debe considerar la capacidad de recepción de la otra parte, sino también la congestión de la red.

Por lo tanto, se introduce una ventana deslizante para enviar datos en paralelo para mejorar la eficiencia.La
ventana deslizante describe que el remitenteLa cantidad máxima de datos que se pueden enviar a la vez sin esperar un ACK

Cuando se recibe la respuesta de confirmación, la ventana se deslizará a la posición del número de serie en la respuesta de confirmación y el tamaño de la ventana cambiará dinámicamente.

Hay dos situaciones en las que se produce la pérdida de paquetes al enviar datos en una ventana deslizante:
1. Ha llegado el paquete de datos y se pierde el ACK.

2. El paquete enviado se pierde

¿Por qué necesita retransmitir horas extras después de una retransmisión rápida?
La retransmisión rápida debe recibir el mismo reconocimiento 3 veces, de lo contrario, no se activará.
Por lo tanto, la retransmisión de tiempo de espera es una estrategia de garantía de fondo para garantizar que se pueda retransmitir después de la pérdida.

②Respuesta retrasada

Si el host que recibe los datos devuelve una respuesta ACK inmediatamente, la ventana devuelta en este momento puede ser relativamente pequeña.
De hecho, la capa superior toma los datos más rápido que la velocidad de respuesta en la red.

Si el extremo receptor espera un momento antes de responder, entonces la capa superior tomará más datos en el búfer. En este momento, el tamaño de la ventana de retorno es mayor
, la ventana es mayor, el rendimiento de la red es mayor y el la eficiencia de transmisión es mayor, lo que mejora la eficiencia de transmisión al tiempo que garantiza que la red no esté congestionada

③Respuesta a cuestas

Mientras responde a la confirmación, también realiza los datos a enviar.El
mensaje no solo puede confirmar, sino también enviar datos.

Por ejemplo, agitar las manos cuatro veces combinará las dos del medio en un solo mensaje.

flujo de bytes

Flujo de bytes:
los datos enviados por TCP son como un flujo ininterrumpido, por lo que se debe evitar el problema de los paquetes pegajosos.

Características:
al enviar datos al búfer y leer los datos en el búfer, no es necesario escribir o leer los datos al mismo tiempo,
es decir, puede escribir o leer los datos arbitrariamente siempre que los datos se escriban o lean .

problema del paquete pegajoso

Paquetes adhesivos: la capa de aplicación lee más o menos paquetes, lo que hace que otros paquetes queden inutilizables

Entonces, ¿cómo evitar el problema del paquete pegajoso?
Aclarar el límite entre dos paquetes

Existen principalmente los siguientes métodos
1. Mensaje de longitud fija, lea el tamaño de longitud fija
2. Caracteres especiales, leer los caracteres especiales significa que se lee el mensaje
3. Tamaño autodescriptivo + longitud fija (UDP) o autodescripción descripción del tamaño + carácter especial (HTTP)

Para el protocolo UDP, ¿existe también un "problema de paquete adhesivo"?
UDP adopta un método autodescriptivo + de longitud fija. Indica que el límite del mensaje está
orientado en segundo lugar a los datagramas UDP, ya sea que se recibe un mensaje UDP completo o no se recibe No. Habrá una situación de "mitad"

Entonces, ¿por qué el protocolo de la capa de aplicación que usa TCP tiene el problema de los paquetes pegajosos?
TCP está orientado a bytes, y los paquetes escritos y leídos pueden estar incompletos, y los paquetes TCP no tienen un campo para identificar la longitud del paquete, y no hay límite entre paquete y paquete. La capa de aplicación necesita resolver este problema sí mismo

Excepciones de TCP

1. Terminación del proceso: la terminación del proceso liberará el descriptor del archivo y aún se puede enviar FIN. No es diferente de un apagado normal.
2. Reinicio de la máquina: matará todos los procesos, al igual que la terminación del proceso.
3. Fallo de alimentación de la máquina/desconexión del cable de red Abierto: el par piensa que la conexión todavía está allí. Una vez que el par tiene una operación de escritura y descubre que la conexión ya no está allí, realizará un reinicio.
Incluso si no hay escritura operación, el propio TCP tiene un temporizador de mantenimiento de conexión incorporado (generalmente implementado por la capa de aplicación), si la otra parte no ha enviado una solicitud durante mucho tiempo, preguntará periódicamente si la otra parte todavía está allí. Si la otra parte no está allí, la conexión también se liberará, o informando periódicamente la seguridad de la otra parte para garantizar que la otra parte todavía existe

el segundo parámetro de escucha

La pila de protocolos del kernel de Linux utiliza dos colas para la administración de una conexión tcp:

1. Cola semi-vinculada (usada para retener solicitudes en estados SYN_SENT y SYN_RECV)
2. Cola de conexión completa (utilizada para guardar conexiones que se encuentran en el estado establecido, se han establecido tres veces y se pueden eliminar directamente al aceptar)

La longitud de la cola de conexión completa se verá afectada por el segundo parámetro de escucha. La longitud de la cola es el segundo parámetro de escucha + 1.
Cuando la cola de conexión completa está llena, no puede continuar permitiendo que el estado de conexión actual ingrese al estado establecido.

¿Por qué hacer cola?
Cuando una conexión se desconecta internamente, se puede seleccionar inmediatamente una conexión de la cola de conexión para su procesamiento, lo que garantiza que el servidor esté cargado casi al 100 %
¿Por qué no puede ser demasiado tiempo?
Si es demasiado largo, aumentará el costo de mantenimiento del servidor, y si es demasiado largo, aumentará el tiempo de espera y hará que el cliente deje de esperar.

Ataque de inundación SYN: