Explicación detallada de UDP y TCP

1. UDP

---

1.1 Formato de segmento de protocolo UDP

• Longitud UDP de 16 bits, que indica la longitud máxima de todo el datagrama (encabezado UDP + datos UDP), es decir, el tamaño máximo del datagrama es 2^16 bytes = 64 KB
• Si la suma de verificación es incorrecta, se descartará directamente

1.2 Características de UDP

1.2.1 Ninguna conexión no es fiable

• Sin conexión
  Conozca la IP y el número de puerto del par y transmita directamente sin establecer una conexión
• No confiable
  No hay mecanismo de confirmación ni mecanismo de retransmisión; si el segmento no se puede enviar a la otra parte debido a una falla en la red, la capa de protocolo UDP no devolverá
  ninguna información de error a la capa de aplicación
  . UDP no garantiza la confiabilidad y la llegada ordenada de datos, por lo que puede haber una secuencia de caos, es necesario administrar la secuencia de paquetes en la capa de aplicación

1.2.2 Orientado a datagramas

• La longitud del mensaje dada por la capa de aplicación a UDP, UDP se envía tal cual, sin dividir ni fusionar, y la longitud máxima es de 64 KB
• Si los datos que necesitamos transmitir exceden los 64K, debemos subempaquetarlos manualmente en la capa de aplicación, enviarlos varias veces y ensamblarlos manualmente en el extremo receptor.

1.3 Búfer UDP

• UDP no tiene un búfer de envío real.La llamada a sendto se transferirá directamente al núcleo, y el núcleo pasará los datos al protocolo de capa de red para las acciones de transmisión posteriores;
• UDP tiene un búfer de recepción, pero este búfer de recepción no puede garantizar que el orden de los paquetes UDP recibidos sea consistente con la secuencia de envío de paquetes UDP, si el búfer está lleno, los datos UDP que llegan se descartarán;
• Los sockets UDP pueden leer y escribir, este concepto se llama  full-duplex

1.4 Protocolos conocidos basados ​​en UDP

• DHCP : protocolo de configuración de host dinámico
• DNS : Protocolo de resolución de nombres de dominio

2.TCP

---

2.1 Formato de segmento de protocolo TCP

• Número de puerto de origen/destino : Indica de qué proceso provienen los datos y a qué proceso van;
• número de serie de 32 bits/número de confirmación de 32 bits : detallado más adelante;
• Longitud del encabezado TCP de 4 bits : indica cuántos bits de 32 bits (cuántos 4 bytes) tiene el encabezado TCP, por lo que la longitud máxima del encabezado TCP es 15 * 4 = 60 bytes
• 6 bits de bandera :
  • URG: si el puntero urgente es válido
  • ACK: si el número de acuse de recibo es válido
  • PSH: solicite a la aplicación final receptora que lea los datos del búfer TCP inmediatamente
  • RST: la otra parte solicita restablecer la conexión; llamamos al segmento que lleva la bandera RST un segmento de reinicio
  • SYN: Solicitud para establecer una conexión, llamamos al identificador SYN como un segmento de sincronización
  • FIN: Notifica a la otra parte que el extremo local se va a cerrar, y llamamos al segmento final que lleva la bandera FIN
• Tamaño de ventana de 16 bits : indica el número de bytes que el destinatario de este mensaje puede recibir del número de secuencia de confirmación (el tamaño del búfer preparado por el destinatario). Debido al área limitada del búfer, evita que la otra parte envíe los datos son demasiado rápidos, lo que provoca la pérdida de datos. En realidad, la opción de 40 bytes del encabezado TCP también incluye un factor de expansión de ventana M, y el tamaño real de la ventana es el valor del campo de la ventana desplazado a la izquierda por M bits;
• Suma de verificación de 16 bits : relleno en el extremo de envío, verificación de CRC. Si falla la verificación en el extremo de recepción, se considera que hay un problema con los datos. La suma de verificación aquí incluye no solo el encabezado TCP, sino también los datos TCP. parte.
• Puntero urgente de 16 bits : identifique qué parte de los datos son datos urgentes;
• Opción de encabezado de 40 bytes : temporalmente ignorada;

2.2 Formato de transmisión de datos TCP

• TCP envía datos en forma de flujo de bytes. No importa qué tipo de datos sean, pero para garantizar la corrección de los datos, el control de retransmisión y el control de repetición, etc., estas funciones se implementan con números de serie. El valor inicial de los números de serie no es 0, sino que es aleatorio. seleccionado por el cliente al establecer una conexión.
• La longitud de datos de TCP no se escribe en el encabezado de TCP. La fórmula para calcular la longitud del paquete TCP en la comunicación real es: la longitud del paquete de datos en el encabezado IP – la longitud del encabezado IP y la longitud del encabezado TCP
• TCP numera cada byte de datos. Es el número de secuencia. Cada ACK tiene un número de secuencia de confirmación correspondiente, lo que significa decirle al remitente qué datos he recibido; ¿dónde empezar a enviar la próxima vez?
  

2.3 Mecanismo de respuesta de acuse de recibo

2.4 Mecanismo de transmisión de tiempo límite

Entonces, ¿cómo determinar el tiempo de espera?

• Lo ideal es encontrar un tiempo mínimo para garantizar que "la respuesta de confirmación debe devolverse dentro de este tiempo".
• Sin embargo, la duración de este tiempo varía según los diferentes entornos de red.
• Si el tiempo de espera es demasiado largo, afectará la eficiencia general de la retransmisión;
• Si el tiempo de espera es demasiado corto, es posible que se envíen paquetes repetidos con frecuencia;

Para garantizar una comunicación de alto rendimiento en cualquier entorno, TCP calculará dinámicamente el período máximo de tiempo de espera.

• En Linux (lo mismo es cierto para BSD Unix y Windows), el tiempo de espera se controla con 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 la retransmisión, espere 2*500ms antes de retransmitir.
• Si aún no hay respuesta, espere 4*500ms para la retransmisión, y así sucesivamente, aumentando exponencialmente.
• Cuando se ha acumulado una cierta cantidad de retransmisiones, TCP considera que la red o el host del mismo nivel es anormal y cierra la conexión a la fuerza.

2.5 Mecanismo de gestión de la respuesta

Transición de estado del servidor:

• [CERRADO -> LISTEN] El servidor entra en estado LISTEN después de llamar a listen, esperando que el cliente se conecte;
• [LISTEN -> SYN_RCVD] Una vez que se monitorea la solicitud de conexión (segmento de sincronización), la conexión se colocará en la cola de espera del kernel y se enviará un mensaje de confirmación SYN al cliente.
• [SYN_RCVD -> ESTABLECIDO] Una vez que el servidor recibe el mensaje de confirmación del cliente, ingresa al estado ESTABLECIDO y puede leer y escribir datos.
• [ESTABLECIDO -> CLOSE_WAIT] Cuando el cliente cierra activamente la conexión (llamando a cerrar), el servidor recibirá el segmento final y devolverá
  el segmento de confirmación e ingresará CLOSE_WAIT;
• [CLOSE_WAIT -> LAST_ACK] Después de ingresar CLOSE_WAIT, significa que el servidor está listo para cerrar la conexión (los datos anteriores deben procesarse); cuando el servidor realmente llame para cerrar la conexión, enviará un FIN al cliente , y en este momento el servidor entra en el estado LAST_ACK, esperando la llegada del último ACK (este ACK es la confirmación de recepción de FIN por parte del cliente)
• [LAST_ACK -> CLOSED] El servidor ha recibido el ACK para FIN y cierra completamente la conexión

Transición de estado del cliente:

• [CERRADO -> SYN_SENT] El cliente llama a connect y envía un segmento de sincronización;
• [SYN_SENT -> ESTABLECIDO] Si la llamada de conexión es exitosa, ingresará al estado ESTABLECIDO y comenzará a leer y escribir datos;
• [ESTABLECIDO -> FIN_WAIT_1] Cuando el cliente llama activamente a cerrar, envía un segmento final al servidor e ingresa FIN_WAIT_1 al mismo tiempo;
• [FIN_WAIT_1 -> FIN_WAIT_2] El cliente recibe la confirmación del servidor del segmento final, luego ingresa FIN_WAIT_2 y comienza a esperar el segmento final del servidor;
• [FIN_WAIT_2 -> TIME_WAIT] El cliente recibe el segmento final del servidor, ingresa TIME_WAIT y envía LAST_ACK;
• [TIME_WAIT -> CLOSED] El cliente esperará un tiempo de 2MSL (vida máxima del segmento, tiempo máximo de supervivencia del mensaje) antes de ingresar al estado CERRADO

¿Por qué un apretón de manos de tres vías?

• Si la solicitud de conexión enviada por el cliente llega al servidor después de que se libere la conexión del cliente debido a un retraso en la red, este es un mensaje que ya ha expirado.Si solo se realiza el segundo apretón de manos, el servidor pensará que hay una nueva conexión. solicitud, pero el cliente no ha establecido una conexión. Los datos se enviarán al servidor, pero el servidor siempre consumirá recursos para esta conexión.

¿Por qué se agita cuatro veces?
Ambas partes deben ponerse de acuerdo para cerrar la conexión.
(1) Para garantizar que el último segmento ACK enviado por el cliente pueda llegar al servidor. Es decir, el último mensaje de confirmación puede perderse y el servidor lo retransmitirá después de un tiempo de espera, luego el servidor envía una solicitud FIN para cerrar la conexión y el cliente envía una confirmación ACK. Un viaje de ida y vuelta son dos ciclos de vida de mensajes.
Si no hay tiempo de espera, si la conexión se libera inmediatamente después de enviar el segmento de confirmación, el servidor no puede retransmitir, por lo que no se puede recibir la confirmación y no se puede ingresar al estado CERRADO de acuerdo con los pasos, es decir, la confirmación debe ser recibido para cerrar.
(2) Evite que aparezcan mensajes de solicitud de conexión no válida en la conexión. Después de 2MSL, todos los segmentos de mensajes generados pueden desaparecer de la red dentro de este período continuo de tiempo.

2.6 TIEMPO_ESPERA

• 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 volver al estado CERRADO .
  • MSL es la vida útil máxima de un mensaje TCP, por lo que si TIME_WAIT persiste durante 2MSL,
    puede garantizar que los segmentos de mensajes retrasados ​​o no recibidos en ambas direcciones de transmisión hayan desaparecido (de lo contrario, el servidor se reinicia inmediatamente y puede recibir mensajes de los datos tardíos superiores para un proceso, pero es probable que estos datos sean incorrectos);
  • Al mismo tiempo, también se garantiza teóricamente que el último mensaje llegue de forma fiable (suponiendo que se pierda el último ACK, el servidor volverá a enviar un FIN. En este momento, aunque el proceso del cliente se ha ido, la conexión TCP sigue ahí). , y el LAST_ACK aún se puede reenviar);
• Usamos Ctrl-C para terminar el servidor, por lo que el servidor es la parte que cierra activamente la conexión, y aún no puede volver a escuchar el mismo puerto del servidor durante TIME_WAIT ;
• MSL se especifica como dos minutos en RFC1122, pero la implementación de cada sistema operativo es diferente.El  valor de configuración predeterminado en Centos7 es 60s , puede verificar el valor de msl a través de cat /proc/sys/net/ipv4/tcp_fin_timeout;

2.6.1 Mejora de TIME_WAIT

No se permite volver a escuchar hasta que la conexión TCP del servidor esté completamente desconectada, lo que puede no ser razonable en algunos casos.

• El servidor necesita manejar una gran cantidad de conexiones de clientes (la duración de cada conexión puede ser muy corta, pero hay una gran cantidad de clientes solicitando cada segundo).
• En este momento, si el lado del servidor cierra activamente la conexión (por ejemplo, si algunos clientes no están activos, el lado del servidor debe limpiarlos activamente), se generará una gran cantidad de conexiones TIME_WAIT.
• Debido a nuestra gran cantidad de solicitudes, puede dar lugar a una gran cantidad de conexiones TIME_WAIT, y cada conexión ocupará un quíntuple de comunicación (ip de origen, puerto de origen, ip de destino, puerto de destino, protocolo), entre ellos, la ip del servidor y port y El protocolo es fijo, si se repite la ip y número de puerto de la nueva conexión del cliente y el link ocupado por TIME_WAIT habrá problemas
• Use setsockopt() para establecer la opción SO_REUSEADDR del descriptor de socket en 1, lo que significa que se pueden crear múltiples descriptores de socket con el mismo número de puerto pero diferentes direcciones IP
• 

2.7 CLOSE_WAIT

En el programa del servidor, si eliminamos new_sock.Close(); este código,
compilamos y ejecutamos el servidor. Iniciamos la conexión del cliente, verificamos el estado de TCP, el servidor del cliente está en el estado ESTABLECIDO, no hay problema. Entonces cierre el programa del cliente y observe el estado de TCP
En este momento, el servidor ha ingresado al estado CLOSE_WAIT y, combinado con el diagrama de flujo de nuestras cuatro manos agitadas, se puede considerar que las cuatro manos agitadas no se han completado correctamente.

• Para una gran cantidad de estados CLOSE_WAIT en el servidor, la razón es que el servidor no cerró el socket correctamente, lo que provocó que las cuatro manos agitadas no se completaran correctamente. Esto es un ERROR. Solo necesita agregar el cierre correspondiente para resolver el problema

2.7 Ventanas correderas

Para cada segmento de datos enviado, se debe dar un ACK para confirmar la respuesta. Después de recibir el ACK, se envía el siguiente segmento de datos.
Esto tiene una desventaja relativamente grande, es decir, un bajo rendimiento. Especialmente para datos de ida y vuelta más largos. Tiempo. Dado que el rendimiento de este método de envío y recepción es bajo, podemos mejorar mucho el rendimiento enviando varios datos a la vez (de hecho, el tiempo de espera de varios segmentos se superpone).

• El tamaño de la ventana se refiere al valor máximo que puede continuar enviando datos sin esperar un reconocimiento. El tamaño de la ventana en la figura anterior es de 4000 bytes (cuatro segmentos).
• Al enviar los primeros cuatro segmentos, no es necesario esperar ningún ACK, solo envíe directamente
• Después de recibir el primer ACK, la ventana deslizante retrocede y continúa enviando los datos del quinto segmento, y así sucesivamente;
• Para mantener esta ventana deslizante, el kernel del sistema operativo necesita crear un búfer de envío para registrar qué datos no han sido respondidos actualmente; solo los datos que han sido respondidos pueden eliminarse del búfer;
• Cuanto mayor sea la ventana, mayor será el rendimiento de la red;
  

Entonces, si hay una pérdida de paquetes, ¿cómo retransmitir? Aquí hay dos situaciones para discutir.

• Caso 1: el paquete de datos llegó y se perdió el ACK: la ventana deslizante maneja la retransmisión
  
  En este caso, no importa si se perdió parte del ACK, porque puede confirmarse con los ACK posteriores:
  1-1000 bytes de datos han se ha enviado al host B, pero se pierde la respuesta de confirmación de datos de 1-1000. Cuando se recibe el número de secuencia de confirmación ACK = 2001, los datos del cliente 1-1000 se pueden eliminar del búfer, porque el host B ha enviado el número de secuencia de confirmación ACK = 2001, lo que indica que los datos 1-1000 se han enviado correctamente.

• Situación 2: el paquete de datos se pierde directamente : control de retransmisión de alta velocidad
  

• Cuando se pierde un determinado segmento, el remitente siempre recibirá ACK como 1001, como recordarle al remitente "Quiero 1001";

• Si el host emisor recibe la misma respuesta "1001" tres veces consecutivas, volverá a enviar los datos correspondientes 1001 - 2000;

• En este momento, después de recibir 1001 en el extremo receptor, el ACK devuelto nuevamente es 7001 (porque 2001 - 7000). El extremo receptor lo recibió antes y se coloca en el búfer de recepción del núcleo del sistema operativo del receptor. fin;

2.8 Control de flujo

La velocidad a la que el extremo receptor puede procesar los datos es limitada. Si el extremo emisor envía demasiado rápido, el búfer del extremo receptor se llenará. En este momento, si el extremo emisor continúa enviando, provocará la pérdida de paquetes, lo que a su vez causará la pérdida de paquetes y la retransmisión, etc. Una serie de reacciones en cadena.
Por lo tanto, TCP admite la determinación de la velocidad de envío del extremo de envío de acuerdo con la capacidad de procesamiento del extremo de recepción. Este mecanismo se denomina control de flujo (Flow Control);

• El extremo receptor coloca el tamaño del búfer que puede recibir en el campo " tamaño de la ventana "  en el encabezado TCP y notifica al extremo emisor a través del extremo ACK;
• Cuanto mayor sea el campo de tamaño de la ventana, mayor será el rendimiento de la red;
• Una vez que el extremo receptor descubre que su búfer está casi lleno, establecerá el tamaño de la ventana en un valor más pequeño y notificará al extremo emisor;
• Después de que el remitente reciba esta ventana, reducirá su velocidad de envío;
• Si el búfer en el extremo receptor está lleno, la ventana se establecerá en 0; en este momento, el remitente ya no enviará datos, pero necesita enviar un segmento de datos de detección de ventana periódicamente, para que el extremo receptor pueda decirle al envío final cómo configurar el
  
  tamaño de la ventana ¿Qué hay de decirle al remitente?Recuerde que en nuestro encabezado TCP, hay un campo de ventana de 16 bits, que almacena la información del tamaño de la ventana, entonces
  surge la pregunta, el número máximo de 16 bits representa 65535 , entonces, ¿la ventana TCP máxima es de 65535 bytes?
  En realidad, la opción de encabezado TCP de 40 bytes también incluye un factor de expansión de ventana M, y el tamaño real de la ventana es el valor del campo de la ventana desplazado a la izquierda por M bits;

2.9 Control de congestión

• Aunque TCP tiene el gran asesino de la ventana deslizante, puede enviar una gran cantidad de datos de manera eficiente y confiable. Sin embargo, si se envía una gran cantidad de datos en la etapa inicial, aún puede causar problemas.
• Debido a que hay muchas computadoras en la red, es posible que el estado actual de la red ya esté relativamente congestionado.Si no conoce el estado actual de la red, es probable que el envío de una gran cantidad de datos precipitadamente empeore las cosas.
• TCP introduce  un mecanismo de inicio lento
  
  , que primero envía una pequeña cantidad de datos, explora la ruta, descubre el estado actual de congestión de la  red y luego decide a qué velocidad transmitir los datos. exponencial "Inicio lento" Simplemente significa que es lento al principio, pero la tasa de crecimiento es muy rápida.
• Para no crecer tan rápido, la ventana de congestión no se puede simplemente duplicar, aquí se introduce un umbral llamado comienzo lento.
• Cuando la ventana de congestión supera este umbral, ya no crece exponencialmente, sino que crece de forma lineal. Una
  
  pequeña cantidad de pérdida de paquetes, solo activamos la retransmisión por tiempo de espera; una gran cantidad de pérdida de paquetes, creemos que la red está congestionada;
  cuando la comunicación TCP comienza Después eso, el rendimiento de la red aumentará gradualmente; a medida que la red se congestione, el rendimiento disminuirá inmediatamente; el
  control de congestión, en el análisis final, es que el protocolo TCP quiere transmitir datos a la otra parte lo más rápido posible, pero debe también evite causar demasiada presión en la red.

2.10 Respuesta retardada

Si el host que recibe los datos devuelve una respuesta ACK inmediatamente, la ventana de devolución puede ser relativamente pequeña en este momento.

• Suponga que el búfer del receptor es de 1 M. Se reciben datos de 500 K a la vez, si la respuesta es inmediata, la ventana devuelta es de 500 K;
• Pero, de hecho, la velocidad de procesamiento del extremo de procesamiento puede ser muy rápida, y se consumirán 500 K datos del búfer en 10 ms;
• En este caso, el procesamiento en el extremo receptor está lejos de llegar a su límite, incluso si la ventana se amplía, aún puede manejarlo;
• Si el extremo receptor espera un momento antes de responder, por ejemplo, espera 200 ms antes de responder, entonces el tamaño de ventana devuelto en este momento es 1 M;

Debe recordarse que cuanto mayor sea la ventana, mayor será el rendimiento de la red y mayor la eficiencia de la transmisión. Nuestro objetivo es mejorar la eficiencia de la transmisión tanto como sea posible y al mismo tiempo garantizar que la red no esté congestionada. ¿Se pueden retrasar todos los paquetes en respuesta? ?Ciertamente

no;

• Límite de cantidad : responde cada N paquetes;
• Límite de tiempo : responda una vez cuando se exceda el tiempo de demora máximo;
  el número específico y el tiempo de espera varían según el sistema operativo; generalmente, N es 2 y el tiempo de espera es de 200 ms

2.11 Llevar a cuestas

Según la respuesta demorada, descubrimos que, en muchos casos, el servidor del cliente también "envía y recibe" en la capa de la aplicación. Esto significa que el cliente dice "¿Cómo estás?" al servidor, y el servidor también responderá a la cliente Un "Bien, gracias";

Luego, en este momento, el ACK puede hacer autostop y enviarlo de regreso al cliente junto con la respuesta "Bien, gracias" del servidor.

2.12 flujo de bytes orientado (MSS)

Cree un socket TCP y cree un búfer de envío y un búfer de recepción en el kernel al mismo tiempo;

• Al llamar a escribir, los datos se escribirán primero en el búfer de envío;
• Si la cantidad de bytes enviados es demasiado larga, se dividirá en varios paquetes TCP y se enviará;
• Si el número de bytes enviados es demasiado corto, esperará en el búfer hasta que la longitud del búfer esté casi llena, o lo enviará en otros momentos adecuados;
• Al recibir datos, los datos también llegan al búfer de recepción del kernel desde el controlador de la tarjeta de red;
• Luego, la aplicación puede llamar a leer para obtener datos del búfer de recepción;
• Por otro lado, una conexión TCP tiene tanto un búfer de envío como un búfer de recepción, por lo que para esta conexión se pueden leer o escribir datos, este concepto se denomina full-duplex.

Debido a la existencia del búfer, la lectura y escritura del programa TCP no necesita coincidir una por una, por ejemplo:

• Al escribir 100 bytes de datos, puede llamar a escribir una vez para escribir 100 bytes, o puede llamar a escribir 100 veces, escribiendo un byte a la vez;
• Al leer 100 bytes de datos, no hay necesidad de considerar cómo escribirlos. Puede leer 100 bytes a la vez, o puede leer un byte a la vez y repetir 100 veces;

Hay un campo de "tamaño de ventana" en el encabezado del segmento TCP, que ocupa 16 bits = 2 bytes. Este campo se usa principalmente para el control de flujo de ventana deslizante de TCP. A muchas personas les gusta confundir el MSS de TCP con el campo "tamaño de ventana". Aquí hay una distinción

MSS es la longitud máxima de la parte de datos en el segmento TCP . Si los datos entregados por la capa superior exceden el MSS, la capa de enlace segmentará los datos entregados. 1500 bytes, si no analiza el tamaño, la capa inferior encapsúlelo usted mismo). En el primer y segundo protocolo de enlace de la conexión TCP, el MSS de la otra parte se notificará respectivamente, para lograr el efecto de negociar el MSS entre las dos partes que se comunican.

En el encabezado del segmento TCP, el campo " tamaño de la ventana " generalmente se usa para informar a la otra parte de su volumen de datos aceptable. La ventana es esencialmente un búfer de búfer, y el valor de este campo se utiliza para informar a la otra parte del tamaño de búfer disponible restante . En cada segmento TCP, el campo "ventana" se utilizará para informar a la otra parte del tamaño de los datos que puede recibir. El tamaño de la ventana generalmente se controla con un flujo de ventana deslizante.

Para otro ejemplo , el tamaño de MTU es como el tonelaje de carga de un puente, y el puente es equivalente a una tarjeta de red;

Dado el MSS por adelantado, puede evitar el transporte por lotes porque su camión tiene demasiada carga;

Si no especifica MSS, una vez que su camión está sobrecargado y el tonelaje excede la capacidad de carga del puente, debe dividir los productos en varios lotes y enviarlos, y debe ensamblarlos después del envío, lo que no vale la pena la vela;

Referencia del artículo : Haga clic en mí para ver el rol de MSS

2.13 Problema del paquete pegajoso

En primer lugar, debe quedar claro que el "paquete" en el problema del paquete adhesivo se refiere al paquete de datos de la capa de aplicación.

• En el encabezado del protocolo de TCP, no hay un campo como "longitud del paquete" como UDP, pero hay un campo como el número de secuencia.
• Desde la perspectiva de la capa de transporte, TCP viene uno por uno y se organizan en el búfer de acuerdo con el número de secuencia.
• Desde la perspectiva de la capa de aplicación, lo que ve es solo una serie de datos de bytes continuos.
• Luego, el programa de aplicación ve una serie de datos de bytes de este tipo y no sabe qué parte comenzar desde qué parte, es un paquete de datos de capa de aplicación completo.

Entonces, ¿cómo evitar el problema del paquete pegajoso? En el análisis final, es una oración, despeje el límite entre dos paquetes.

• Para un paquete de longitud fija, asegúrese de que se lea en un tamaño fijo cada vez; por ejemplo, la estructura de solicitud anterior tiene un tamaño fijo, luego se puede leer desde el principio del búfer de acuerdo con el tamaño de (Solicitud);
• Para paquetes de longitud variable, puede especificar un campo para la longitud total del paquete en el encabezado del paquete, para que sepa la posición final del paquete;
• Para paquetes de longitud variable, también puede usar un separador claro entre paquetes (el protocolo de la capa de aplicación lo determina el propio programador, siempre que el separador no entre en conflicto con el texto);

Pensando: Para el protocolo UDP, ¿hay también un "problema de paquete pegajoso"?

• Para UDP, si la capa superior no ha entregado datos, la longitud del paquete UDP todavía está allí. Al mismo tiempo, UDP entrega datos a la capa de aplicación uno por uno. Hay un límite de datos claro.
• Desde la perspectiva de la capa de aplicación, cuando se usa UDP, se recibe o no un paquete UDP completo. No habrá una situación "a medias".

2.14 Resumen de TCP

¿Por qué TCP es tan complicado?, porque es necesario para garantizar la fiabilidad y al mismo tiempo mejorar el rendimiento tanto como sea posible.

fiabilidad:

• suma de control
• Número de serie (llega en orden)
• respuesta de confirmación
• tiempo de espera reenviar
• gestión de conexiones
• control de flujo
• control de congestión

Mejorar el rendimiento:

• ventana deslizante
• retransmisión rápida
• respuesta tardía
• a cuestas

otro:

• Temporizador (temporizador de retransmisión de tiempo extra, temporizador de mantenimiento, temporizador TIME_WAIT, etc.)

2.15 Basado en el protocolo de capa de aplicación TCP

• HTTP
• HTTPS
• SSH
• Telnet
• FTP
• SMTP

3. Escenarios de aplicación UDP y TCP

Escenarios de aplicación de UDP

• Escenarios con requisitos de alta velocidad: el protocolo UDP se puede usar para chatear por video o ver transmisiones en vivo, porque incluso si se pierden algunos cuadros, el impacto en los usuarios no es grande

Escenarios de aplicación de TCP

• En la escena de envío de mensajes y transferencia de archivos y navegación web, es necesario asegurarse de que los mensajes enviados no se pierdan

Si solo comprende los dos anteriores, será inútil. De hecho, debido a la rápida velocidad de transmisión de UDP, los escenarios de aplicación son mucho más grandes que los de TCP. Incluso en HTTP, el último HTTP 3.0 ya ha entregado UDP. Común Los chats QQ también son UDP (TCP adaptativo de tiempo de red deficiente), pero es necesario resolver la pérdida de datos en la capa de aplicación. Por lo tanto, se puede decir

¡UDP es el dios eterno!