Abra el software de comida para llevar y muestre la lista de comerciantes. Hay muchos elementos en la lista y cada elemento contiene cierta información: el nombre del comerciante, imagen, calificación positiva, ubicación de usted, calificación...

Para estas operaciones hemos realizado los siguientes diseños:

1. Aclarar qué información se incluye en la solicitud y respuesta actual (según requisitos)

Solicitud: identidad del usuario, ubicación actual del usuario

Respuesta: Contiene información comercial diversa.

2. Aclarar los formatos específicos de solicitud y respuesta.

Ejemplo uno:

El llamado formato claro depende de cómo se construye una cadena, que luego se puede transmitir como una carga útil TCP o UDP.

Por otro lado, el servidor puede analizar esta cadena y determinar que el ID de usuario está antes de la coma y que la longitud y la latitud están después de la coma.

En este momento, hemos construido una cadena de respuesta y el cliente puede analizarla de acuerdo con este formato.

Los datos transmitidos en la red son esencialmente una cadena (para ser precisos, una "cadena" binaria) y es imposible transmitir directamente contenido como un objeto Java.

Al escribir código en Java, a menudo hay varios objetos

Pero al enviar datos al final, es necesario convertir el objeto en una cadena (binaria) [serialización]

Al recibir datos, también necesita convertir la cadena (binaria) nuevamente al objeto [deserialización]

Ejemplo dos:

¡usar! Para dividir cada comerciante, utilice cada información del comerciante; para dividir

Ejemplo tres:

Del método anterior se puede ver que la forma de organización de datos específica de solicitudes y respuestas es muy flexible. Los programadores pueden organizarla como quieran, sólo necesitan asegurarse de que el cliente y el servidor utilicen las mismas reglas .

2. Formato de protocolo común

Aunque decimos que los formatos de protocolo personalizados pueden ser arbitrarios, para evitar diseños demasiado extravagantes, algunas personas han inventado algunos "formatos de protocolo universales" y, al referirnos a estos formatos, podemos tomar decisiones sobre el diseño de nuestro protocolo.

Dado que hay muchas formas de expresión, aquí seleccionaremos algunas importantes y las presentaremos.

(1) xml

Las etiquetas emparejadas se utilizan para representar información de "pares clave-valor", y se admite el anidamiento de etiquetas para formar datos con estructura de árbol más complejos.

Ventajas: xml expresa datos estructurados muy claramente

Desventajas: la representación de datos requiere la introducción de una gran cantidad de etiquetas, lo que parece engorroso y también consume mucho ancho de banda de la red.

(2) json

json es la forma de organización de datos más popular

Es esencialmente un par clave-valor, pero parece mucho más limpio que xml.

En json, {} se usa para representar pares clave-valor y [] se usa para representar matrices.

Cada elemento de la matriz puede ser un número, una cadena u otro { } o [ ]

Ventajas: en comparación con xml, los datos representados son mucho más simples y legibles, lo que facilita a los programadores observar los resultados y depurar problemas.

Desventaja: después de todo, se requiere una cierta cantidad de ancho de banda para transmitir el nombre de la clave.

json no es sensible a los saltos de línea, si todos estos contenidos se colocan en la misma línea, es completamente legal.

Generalmente, durante la transmisión de red, json se comprimirá (se eliminan los saltos de línea y los espacios innecesarios) y todos los datos se colocarán en una línea para recuperarlos, y el ancho de banda total ocupado será menor (lo que afectará la legibilidad).

(3)protobúfer

Un conjunto de métodos de serialización de datos binarios propuestos por Google.

Utilice el método binario para acordar una cierta cantidad de bytes para representar qué atributo

Ahorre espacio al máximo (no es necesario transmitir la clave, distinga cada atributo según su posición y longitud)

Ventajas: Ahorre ancho de banda, maximice la eficiencia

Desventajas: los datos binarios no se pueden observar directamente a simple vista, son inconvenientes para la depuración y son complicados de usar (debe escribir un archivo proto especial para describir cómo se ven los datos)

Esto se utiliza principalmente para escenarios con mayores requisitos de rendimiento.

2. Capa de transporte

1、UDP

Características básicas de UDP: sin conexión, transmisión poco confiable, orientada a datagramas, full duplex

Para aprender un protocolo, por supuesto, es necesario dominar las características del protocolo y también es necesario comprender el formato del mensaje del protocolo.

¿Qué hay en la cabecera? Que significa todo esto?

Una comunicación involucra cinco tuplas:

Puerto de origen, puerto de destino, IP de origen, IP de destino, tipo de protocolo

El rango válido de números de puerto legales es 0 - 65535. De hecho, no se utilizará 0.

Entre ellos, el sistema otorga significados específicos al 1 - 1024 (números de puerto conocidos) y, por lo general, no se recomienda su uso.

Por supuesto, también puedes escribir un programa para usar puertos anteriores al 1024 (tu programa necesita derechos de administrador)

Durante el proceso de transmisión de datos a través de la red, los datos pueden dañarse debido a interferencias externas.

Los datos de la red son esencialmente señales ópticas/señales eléctricas/ondas electromagnéticas.

Después de ser interferido por el mundo exterior, puede causar errores en los datos que desea transmitir, como 0 -> 1, 1 -> 0

Una vez que el receptor recibe los datos, debe confirmar si los datos son incorrectos. La suma de verificación es un método simple y efectivo.

La suma de verificación real no es solo una "longitud", sino que se genera en función del contenido de los datos. Cuando el contenido cambia, se puede detectar un error.

¿Cómo se implementa la suma de comprobación UDP?

Se utiliza un algoritmo de verificación CRC simple y tosco (suma de verificación de redundancia cíclica)

Acumule cada byte en el datagrama UDP por turno y guarde el resultado acumulado en una variable de dos bytes.

Puede que se desborde a medida que agrega más, pero no importa si se desborda.

Después de agregar todos los bytes, finalmente se obtiene la suma de verificación.

Al transmitir datos, los datos originales y la suma de verificación se transmitirán juntos. El receptor recibe los datos y también recibe la suma de verificación (suma de verificación anterior) enviada por el remitente.

El receptor lo calcula nuevamente de la misma manera para obtener una nueva suma de verificación. Si la suma de verificación anterior y la nueva suma de verificación son iguales, se puede considerar correcta durante el proceso de transmisión de datos. De lo contrario, se considera como durante el proceso de transmisión. los datos estan mal

Sin embargo, la misma suma de verificación no significa necesariamente que los datos sean los mismos, pero la probabilidad de que esto suceda es relativamente baja.

También existen otros algoritmos de verificación que pueden lograr una mayor precisión, pero cuestan más.

2、TCP

(1) Formato de segmento del protocolo TCP:

Características de TCP: conexión, transmisión confiable, orientada al flujo de bytes, full duplex

El kernel implementa la transmisión confiable y no se puede percibir al escribir código (el costo de percepción es bajo y el costo de uso también es bajo)

(2) Mecanismo de implementación de transmisión confiable:

Mecanismo de respuesta de confirmación (confiabilidad):

La respuesta de confirmación es el mecanismo central para garantizar la "confiabilidad"

Cuando enviamos múltiples datos continuamente, los múltiples datos pueden aparecer en una situación de "último servido, primero servido": un datagrama se envía primero y otro datagrama se envía más tarde, pero el último datagrama se envía más tarde. Llegó primero

¿Por qué ocurre la situación de "el último en llegar, primero en llegar"?

Hay muchas rutas desde A --> B en la red. Es posible que dos datagramas no necesariamente tomen la misma ruta desde A --> B.

Además, cada nodo (enrutador/conmutador) está ocupado en diferentes niveles, en este momento habrá diferencias en el proceso de reenvío.

¿Cómo resolver el problema anterior?

Numera los datos

Dado que TCP está orientado a flujos de bytes y no se transmite en unidades de "barras", numeramos los bytes.

(1) Número de bytes, no "barras"

(2) El mensaje de respuesta también debe estar asociado con los datos recibidos, no iguales.

Siempre que conozca el número inicial de esta cadena de bytes y la longitud de los bytes, naturalmente sabrá el número de cada byte.

Solo necesita indicar el número del primer byte de esta cadena de bytes en el encabezado TCP y luego combinarlo con la longitud del mensaje, en este momento se determina el número de cada byte.

El valor del número de secuencia de confirmación es el número del último byte recibido más uno.

En el diagrama de estructura anterior, la parte del número de serie de 32 bits almacena el número del primer byte de esta cadena de bytes.

Los datos almacenan los datos de carga útil de TCP, que contienen varios bytes.

El campo de número de secuencia de confirmación de 32 bits se utiliza para los mensajes de respuesta.

¿Cómo distinguir si el mensaje actual es un mensaje normal o un mensaje de respuesta de confirmación?

Mire las seis banderas, centrándose en la segunda bandera: ACK

ACK = 0 significa que este es un mensaje normal y solo el número de secuencia de 32 bits es válido en este momento

ACK = 1 indica que se trata de un mensaje de respuesta y que tanto el número de secuencia como el número de secuencia de confirmación de este mensaje son válidos.

No existe correlación entre el número de secuencia del mensaje de confirmación y el número de secuencia del mensaje normal. El número de secuencia es el número de datos enviados por su propio host.

A veces, ack también se utiliza para referirse al mensaje de respuesta.

La respuesta de confirmación es el mecanismo central de TCP para garantizar la confiabilidad.

Mecanismo de retransmisión de tiempo de espera (fiabilidad):

Pérdida de paquetes: en la red, es muy probable que se envíe un dato y luego se pierda.

Los enrutadores/conmutadores pueden entenderse como "centros de transporte" que conectan muchos dispositivos.

La estructura es compleja y la cantidad de datos transmitidos también es incierta: a veces se transmiten más datos, a veces se transmiten menos datos.

Si el dispositivo está demasiado ocupado, es posible que se descarten nuevos datos si espera demasiado.

Cuanto mayor sea la carga de la red, más ocupada estará y más fácil será perder paquetes

¿Cómo lidiar con la pérdida de paquetes?

Realizar retransmisión de tiempo de espera

La retransmisión por tiempo de espera equivale a un complemento importante de la respuesta de confirmación.

La retransmisión por tiempo de espera tiene las dos situaciones anteriores:

La primera es que el mensaje enviado se pierde y la segunda es que se pierde el mensaje de respuesta.

Pero el remitente no puede distinguir en qué caso

Como no se puede distinguir, retransmítalos todos.

Pero en el segundo escenario, B recibió el mismo mensaje dos veces, pero suponiendo que se transfirieron 10 yuanes en este momento, pero debido a la retransmisión, se transfirieron 20 yuanes, por lo que hay un problema aquí.

Después de recibir los datos, el receptor debe deduplicar los datos y descartar los datos duplicados para garantizar que cuando la aplicación llame a inputStream.read, los datos leídos no se repitan.

¿Cómo eliminar duplicados? ¿Cómo determinar de manera eficiente si los datos recibidos actualmente están duplicados?

Utilice directamente el número de secuencia TCP como base para el juicio

TCP organizará un espacio de memoria para cada objeto de socket en el kernel, lo que equivale a una cola, también llamada "búfer de recepción", y los datos recibidos se colocarán en el búfer y se ordenarán según el número de serie .

Organizar de acuerdo con el número de serie puede garantizar que incluso si existe una situación de último en llegar, primero en llegar, los datos leídos por la aplicación seguirán estando en orden.

En este punto, puede averiguar fácilmente si los datos recién recibidos están duplicados.

Después de leer los datos, ¿seguirán estando en la cola?

Se trata nuevamente del modelo productor-consumidor.

Después de recibir los datos, la tarjeta de red del receptor coloca los datos en el búfer de recepción del objeto de socket correspondiente (en el kernel).

La aplicación llama a lectura para consumir datos de este búfer de recepción. Cuando la lectura desaparece, los datos se pueden recuperar de la cola (generalmente, la lectura los eliminará después de leerlos).

¿Por qué se pueden transferir los datos durante la retransmisión?

La pérdida de paquetes es esencialmente un problema probabilístico

Suponiendo que la probabilidad de pérdida de paquetes es del 10% y la probabilidad de transmisión exitosa es del 90%, entonces la probabilidad de dos pérdidas de paquetes consecutivas es solo del 1%

A medida que aumenta el número de retransmisiones, la probabilidad general de transmisión exitosa es mayor.

¿Cuánto dura el tiempo de espera?

No necesitamos recordar este valor especialmente

El tiempo de espera no es un valor fijo y aumentará aún más a medida que aumenten las rondas de tiempo de espera.

A medida que aumenta el número de rondas de retransmisión, el tiempo de espera será cada vez más largo.

Esto se debe a que actualmente se cree que, en circunstancias normales, la segunda retransmisión tiene una alta probabilidad de ser exitosa. Si fallan varias retransmisiones, significa que la tasa de pérdida de paquetes de la red actual ya es muy alta. Es posible que haya encontrado algunos faltas graves

En este punto, las retransmisiones frecuentes son una pérdida de esfuerzo y ampliar el intervalo de tiempo también deja espacio para la recuperación de la red.

Sin embargo, el número de rondas de retransmisión de tiempo de espera no es ilimitado: cuando el número de retransmisiones alcanza un cierto nivel, se intentará "restablecer" la conexión TCP.

Esto implica el mensaje de reinicio de TCP.

Cuando RST = 1, significa un mensaje de reinicio. Si la red ha experimentado una falla grave, la operación de reinicio / operación de reinicio no tendrá éxito y la conexión deberá abandonarse al final.

Mecanismo de gestión de conexión (fiabilidad):

La gestión de la conexión, para decirlo sin rodeos, son dos cosas:

1. Establecer una conexión (apretón de manos de tres vías)

2. Desconectar (saludar cuatro veces )

Tres apretones de manos:

apretón de manos

Envíe datos de saludo (estos datos no contienen información comercial) y utilice el saludo para desencadenar escenarios específicos.

Para completar el proceso de establecimiento de una conexión, A y B necesitan datos para saludar tres veces.

Una vez completadas estas cuatro interacciones, se establece la conexión y ambas partes guardan la información sobre la otra parte.

Parecen cuatro veces, pero las dos del medio se pueden combinar en una.

¿Por qué fusionarse?

Después de la fusión, se ahorra el proceso de encapsulación y separación, se reduce el costo y se mejora la eficiencia. En principio, fusionar si es posible.

SYN es una solicitud para establecer una conexión, "segmento de sincronización"

Si SYN = 1, es un segmento de sincronización, lo que significa que un host está intentando establecer una conexión con otro host.

¿Cuál es el proceso del protocolo de enlace de tres vías TCP?

Esta imagen representa vívidamente el proceso de apretón de manos de tres vías.

Apretón de manos de tres vías, el primer SYN debe ser iniciado por el cliente

Este código inicia el protocolo de enlace de tres vías y, una vez completada la nueva operación, se completa el protocolo de enlace de tres vías.

Apretón de manos de tres vías, este es el trabajo realizado por el kernel, la aplicación no puede intervenir aquí

Al mismo tiempo, el servidor no necesita involucrar ningún código de capa de aplicación para el protocolo de enlace de tres vías, solo necesita que su proceso esté vinculado a la interfaz TCP correspondiente y el protocolo de enlace de tres vías se puede completar automáticamente en el kernel. , independientemente de tu ¿Cómo se escribe el código?

Una vez completado el protocolo de enlace de tres vías, tanto el cliente como el servidor forman una conexión.

En este punto, aceptar puede regresar, sacar el elemento principal de la cola de conexión y obtener aún más el objeto socket para comunicarse con el par.

Pero aceptar no participará en el proceso de protocolo de enlace de tres vías.

Servidor TCP de un solo subproceso, cuando el servidor está procesando al primer cliente, aunque no puede llamar a aceptar por segunda vez, no afecta el trabajo del kernel. El kernel ha completado el protocolo de enlace de tres vías con el segundo cliente y el objeto formado está en la cola de conexión.

Es decir, se ha formado la conexión, pero nadie la saca de la cola, el trabajo de aceptación es sacar los elementos de la cola.

¿Cuál es el significado del apretón de manos de tres vías y qué propósito se pretende lograr?

El protocolo de enlace de tres vías también es un mecanismo para garantizar la confiabilidad.

Para que TCP garantice una transmisión confiable, el requisito previo para una transmisión confiable es que la ruta de la red sea fluida.

El protocolo de enlace de tres vías de TCP es verificar si la comunicación con la red es fluida y verificar las capacidades de envío y recepción de cada host.

Esto es similar a cómo el metro hace circular un tren vacío todas las mañanas para evitar posibles fallos en una determinada línea.

Tres apretones de manos, ¿por qué tres veces?

Exactamente tres veces se puede verificar que las capacidades de envío y recepción de ambas partes son normales.

Aunque el protocolo de enlace bidireccional puede verificar la exactitud de las capacidades de comunicación del dispositivo, el servidor no tiene forma de conocer la información que pasó la verificación.

Cuatro veces está bien, pero no es necesario (dividir el tiempo intermedio en dos). Una vez es suficiente. Si puedes fusionarlo, fusionarlo. Dividirlo en dos veces reduce la eficiencia.

El apretón de manos de tres vías también puede tener el efecto de "negociación de mensajes".

La comunicación implica algunos parámetros, que requieren que ambas partes sean coherentes y determinen los parámetros colectivos mediante la negociación.

Durante el proceso de comunicación TCP, en realidad hay mucha información que debe negociarse.

Por ejemplo, ¿dónde empiezan los números de serie de ambas partes?

Esto es para garantizar que los números de secuencia de los mensajes puedan ser bastante diferentes entre dos conexiones, de modo que sea mejor determinar si un mensaje pertenece a esta conexión.

Por ejemplo: los mensajes transmitidos en la red pueden llegar primero. En casos extremos, un determinado mensaje puede llegar tarde por mucho tiempo. Cuando el mensaje llega al otro extremo, el servidor y el cliente han desconectado la conexión anterior. Esta es una re- conexión establecida.

En este momento, podrás identificar claramente a través del número de secuencia que este es el mensaje de la conexión anterior y podrás descartarlo.

En resumen, la intención original del apretón de manos de tres vías es doble:

(1) Solicite direcciones y verifique si la comunicación es fluida y si las capacidades de envío/recepción de ambas partes son normales.

(2) Negociar los parámetros necesarios para que el cliente y el servidor utilicen los mismos parámetros para la transmisión de mensajes

Cuatro olas:

Durante la conexión, ambas partes de la comunicación guardan en su memoria la información relevante del otro extremo.

Pero si la conexión ya no es necesaria, el espacio de almacenamiento anterior debe liberarse a tiempo.

El proceso de agitar cuatro veces es muy similar al de agitar tres veces.

El cliente debe iniciar tres oleadas; el servidor o el cliente pueden iniciar cuatro oleadas (en su mayoría)

FIN es una de las seis banderas

Cuando FIN = 1, significa el final del segmento del mensaje.

Después de los cuatro pasos anteriores, la conexión ya no se utilizará y ambas partes podrán liberar su propio espacio para guardar los mensajes del interlocutor.

¿Por qué saludar cuatro veces? ¿Pueden ser tres veces?

A veces, saludar cuatro veces se puede hacer tres veces, pero otras veces no.

La activación de FIN está controlada por el código de la aplicación. Cuando se llama a socket.close () o finaliza el proceso, se activará FIN.

Por el contrario, ACK está controlado por el kernel y ACK se devolverá inmediatamente después de recibir FIN.

Es difícil decir cuándo se ejecuta este cierre, depende de cómo esté escrito su código.

En el código anterior, el cierre se ejecuta muy rápidamente: tan pronto como el cliente se desconecta, el servidor lo detectará inmediatamente, finalizará el ciclo y activará el cierre.

Pero si el servidor necesita hacer muchos otros trabajos de acabado, la ejecución de close será muy lenta.

Cuando el cierre se activa rápidamente, puede fusionarse con el ACK anterior.

Si el cierre se activa lentamente, no se puede fusionar con el ACK anterior.

¿Qué pasará si el servidor nunca se cierra?

En este momento, el TCP del servidor está en el estado CLOSE_WAIT

Desde la perspectiva del servidor, aunque la conexión aquí no está cerrada, ya no se puede utilizar normalmente.

Al realizar una operación de lectura en el socket actual, si los datos aún no se han leído (todavía hay datos en el búfer), se pueden leer normalmente; si los datos se han leído, se leerá EOF en este momento (por ejemplo flujos de bytes, devuelve - 1. Si es scanner.hasNext, será falso)

Realizar una operación de escritura en el socket actual activará directamente una excepción.

De todos modos, la conexión ya no es útil y cerrar es la única opción.

En casos más extremos, por ejemplo, si se escribe un ERROR en el código, se olvida cerrar.

En este momento, desde la perspectiva del cliente, el FIN de la otra parte no se ha recibido durante mucho tiempo y esperará.

Si no espera durante mucho tiempo, la conexión se abandonará unilateralmente en este momento y el cliente eliminará directamente la información del par que ha guardado y la liberará.

Al liberar recursos, es mejor si ambas partes pueden liberarlos sin problemas, si las condiciones no lo permiten, no afectará la liberación unilateral del cliente.

¿Qué debo hacer si se produce una pérdida de paquetes durante la comunicación?

Esto también implica la retransmisión por tiempo de espera.

El apretón de manos de tres vías y el saludo de cuatro vías también tienen un mecanismo de retransmisión.

Retransmitirá tanto como sea posible. Si la retransmisión aún falla varias veces seguidas, la conexión se liberará unilateralmente.

Si se pierde el primer conjunto de FIN/ACK, A puede retransmitir directamente el FIN.

Si se pierde el segundo conjunto de FIN/ACK, concéntrese en la pérdida de ACK

En el área rodeada por un círculo en la imagen, ¿puede A liberar directamente la conexión en este momento?

No, porque es posible que aún se pierda el último ACK.

Si se pierde el último ACK, B retransmitirá un FIN

En este momento, si A ha liberado la conexión, nadie podrá confirmar el FIN retransmitido.

Por lo tanto, debe dejar que A espere un momento después de enviar el último ACK (principalmente para ver si la otra parte recibirá un FIN retransmitido durante el proceso de espera. Si espera un período de tiempo, la otra parte no lo ha retransmitido). .FIN, se considera que el ACK ha sido recibido por la otra parte)

En este punto, A puede liberar correctamente la conexión.

¿Cuánto tiempo espera A hasta que se libere la conexión?

El tiempo de espera es el tiempo máximo de transmisión entre dos puntos cualesquiera de la red (MSL) * 2

El tiempo de espera de retransmisión debe ser <= MSL

Si el tiempo de espera alcanza MSL, el 100% de los paquetes se han perdido. Si el tiempo de espera se establece mayor, no tendrá sentido.

También hay casos extremos. Por ejemplo, mientras A espera un tiempo de 2 MSL, B retransmite FIN muchas veces y estos FIN se pierden (teóricamente).

Si esta situación realmente ocurre, la red actual debe haber sufrido una falla grave, en este momento no se cumple el requisito previo de "transmisión confiable", por lo que no importa si A libera unilateralmente los recursos.

Mecanismo de ventana corredera (eficiencia):

Mejorar la eficiencia de la transmisión (más precisamente, dejar que TCP no sea demasiado eficiente bajo la premisa de una transmisión confiable) (compensarlo)

El uso de una ventana deslizante no puede hacer que TCP sea más rápido que UDP, pero puede reducir la brecha

No hay una ventana deslizante, lo que puede garantizar la confiabilidad, pero se pasa mucho tiempo esperando ACK.

El propósito de utilizar una ventana corredera es reducir el tiempo de espera anterior.

Envíe un conjunto de datos a la vez. Durante el proceso de envío de este conjunto de datos, no necesita esperar ACK, simplemente envíelo hacia adelante.

En este momento, equivale a usar solo "un tiempo de espera" para esperar 4 ACK.

La cantidad de datos que se pueden enviar a la vez sin esperar ACK se llama "ventana"

Cuanto mayor sea la ventana, mayores serán los datos enviados en lotes y mayor será la eficiencia.

Sin embargo, la ventana no puede ser infinitamente grande, si es infinitamente grande equivale a no tener que esperar ACK en absoluto, en este momento es casi lo mismo que una transmisión no confiable.

Si es infinito, es posible que el receptor no pueda manejarlo y que el equipo de red en el medio no pueda soportarlo.

Actualmente, A envía datos de 1001 a 5000 en lotes a B y necesita esperar 4 ACK correspondientes.

El orden de llegada de estos cuatro ACK también es el primero y el último.

Cuando 2001 llegue al host A, ¿debería A continuar enviando el siguiente mensaje? ¿O A necesita esperar a que llegue 5001 antes de continuar enviando el siguiente mensaje?

Después de recibir el ACK de 2001, A envía inmediatamente los datos de 5001 a 6000. En este momento, el ACK que A está esperando es 3001-6000.

Todavía esperando cuatro ACK, pero retrocedí una cuadrícula

Intuitivamente, parece que la ventana ha retrocedido un paso.

La ventana deslizante es una metáfora vívida, que esencialmente consiste en enviar datos en lotes.

Esto puede acortar el tiempo de espera y mejorar la eficiencia hasta cierto punto que antes (pero aún no más que UDP)

Ahora bien, si transmitimos de esta manera por lotes, ¿qué debemos hacer si los paquetes se pierden en el medio?

Para TCP, mejorar la eficiencia no debería afectar la confiabilidad.

Dos situaciones:

(1) Se pierden datos

(2) ACK perdido

1. ACK perdido

Si se pierde el ACK, no es necesario realizar ningún procesamiento, lo cual también es correcto.

Número de secuencia de confirmación de 2001, que indica que se han recibido todos los datos anteriores a 2001, incluidos 1-1000

Aunque A no recibió el ACK de 1001, el ACK de 2001 cubre el significado de 1001

A menos que se pierdan todos los ACK (se produce una falla importante en la red), de lo contrario, solo se perderá una parte de los ACK, lo que no tiene ningún impacto en la transmisión confiable.

2. El datagrama se pierde.

En este momento, es necesaria la retransmisión.

Después de perder 1001-2000, los datos 2001-3000 llegan a B y el número de secuencia de confirmación devuelto por B sigue siendo 1001.

B luego le pide a A los datos 1001

Aunque los datos posteriores de A a B se pueden transmitir sin problemas, siempre que los datos 1001 no estén disponibles, B siempre solicitará los datos 1001 de A (el número de secuencia de confirmación ACK devuelto es siempre 1001).

Cuando A recibe los datos solicitando 1001 de B varias veces seguidas, A entenderá que 1001 se ha perdido y A retransmitirá los datos 1001-2000.

Cuando el 1001 retransmitido llega a B, el ACK devuelto por B es 7000.

Si al búfer de recepción le falta este bloque, el ACK devuelto siempre solicitará el datagrama 1001. Una vez que se agrega el datagrama 1001, no es necesario retransmitir los datos después de 1001 - 2000 (todos permanecen en el búfer)

A continuación, verifique si faltan datos en los siguientes datos. Si faltan algunos, solicite los datos correspondientes. Si no faltan, simplemente solicite los siguientes datos de los últimos datos en el búfer.

En este punto, equivale a utilizar el costo mínimo para completar la operación de retransmisión de datos.

(Solo se retransmiten los datos perdidos, los demás datos no se repiten)

A esto lo llamamos retransmisión rápida: es una retransmisión de tiempo de espera combinada con una operación de deformación generada bajo una ventana deslizante, en esencia, sigue siendo una retransmisión de tiempo de espera.

La ventana deslizante no significa necesariamente que el uso de TCP implique

Si las partes comunicantes transmiten datos a gran escala, debe ser una ventana deslizante (retransmisión rápida)

Si el tamaño de los datos transmitidos por ambas partes que se comunican es relativamente pequeño, la ventana deslizante no se utilizará en este momento (retransmisión de tiempo de espera)

Mecanismo de control de flujo (fiabilidad):

Como complemento a las ventanas correderas

Ventana deslizante, cuanto más grande es la ventana, mayor es la eficiencia de transmisión, pero la ventana no puede ser infinitamente grande. Si la ventana es demasiado grande, es posible que el receptor no pueda manejarla o que el enlace intermedio de transmisión no pueda para manejarlo.

Esto provocará la pérdida y retransmisión de paquetes. La ventana no mejora la eficiencia, pero en realidad la afecta.

El control de flujo consiste en aplicar los frenos en la ventana deslizante: para evitar que la ventana sea demasiado grande y que el receptor no pueda procesarla.

Este es un modelo productor-consumidor:

La velocidad de producción aquí es muy rápida, pero la velocidad de consumo aquí B no puede seguir el ritmo.

Habrá más y más buffers de recepción y eventualmente estarán llenos. Si continúa enviando datos después de que estén llenos, se producirá la pérdida de paquetes.

Por lo tanto, el control de flujo consiste en limitar la velocidad de envío (tamaño de la ventana) del remitente en función de las capacidades de procesamiento del receptor.

¿Cómo medir la velocidad de procesamiento del receptor?

Aquí utilizamos el espacio restante del búfer de recepción como medida.

Cuanto mayor sea el espacio restante, más rápido consumirá datos la aplicación

Aquí, el espacio restante del búfer de recepción se enviará directamente al remitente a través del mensaje ACK, como base de referencia para el tamaño de la ventana de la próxima transmisión de datos del remitente.

Mecanismo de control de congestión (fiabilidad):

La eficiencia de transmisión general es un efecto barril y depende de la tabla más corta.

En el proceso de transmisión de datos de A a B, tienen que pasar a través de muchos conmutadores/enrutadores, lo que forma un enlace de transmisión relativamente largo.

Si hay un enlace en el medio donde la capacidad de reenvío es particularmente pobre, entonces la velocidad de envío de A no debe exceder el umbral aquí.

¿Cómo medir específicamente la capacidad de reenvío del dispositivo intermedio?

Aquí, no cuantificaremos la capacidad de reenvío del dispositivo intermedio, sino que adoptaremos un enfoque "experimental" para ajustarlo dinámicamente para generar un tamaño de ventana apropiado.

Trate todo el equipo en el medio como un todo.

(1) Utilice una ventana más pequeña para la transmisión. Si la transmisión es suave, aumente el tamaño de la ventana.

(2) Utilice una ventana más grande para la transmisión. Si se pierden paquetes durante la transmisión (se produce congestión), ajuste la ventana a un tamaño más pequeño.

De esta manera, también podrá adaptarse muy bien a los cambios dinámicos del entorno de red.

Ventana de congestión: el tamaño de ventana utilizado bajo el mecanismo de control de congestión

En TCP, el control de la congestión se desarrolla específicamente de la siguiente manera :

1. Inicio lento: cuando se inicia la comunicación por primera vez, se utilizará una ventana muy pequeña para probar el agua primero.

Porque si la red está congestionada y hay mucho tráfico, el ancho de banda de la red que no es rico empeorará.

2. Crecimiento exponencial: durante el proceso de transmisión fluida, la ventana de congestión crecerá exponencialmente (*2)

La tasa de crecimiento exponencial es extremadamente rápida, por lo que no puede ser ilimitada, de lo contrario aparecerán valores muy grandes.

3. Crecimiento lineal: crecimiento exponencial. Cuando la ventana de congestión alcanza un umbral, se convertirá de crecimiento exponencial a crecimiento lineal (+ n)

El crecimiento exponencial y el crecimiento lineal aquí se basan en las rondas de transmisión.

Por ejemplo: ahora que el tamaño de ventana dado es 4000, después de enviar tantos datos como 4000, esta ronda termina. Después de recibir el ACK, continúo enviando datos y entro en la siguiente ronda.

El crecimiento lineal también es crecimiento, lo que hará que la velocidad de envío sea cada vez más rápida. Cuando alcanza un cierto nivel, se acerca al límite de transmisión de la red y puede producirse una pérdida de paquetes.

4. La ventana de congestión vuelve a la ventana pequeña: cuando aumenta el tamaño de la ventana, si se produce una pérdida de paquetes durante la transmisión, se considera que la red actual está congestionada. En este momento, el tamaño de la ventana se ajustará a la ventana pequeña original y Continuar volviendo al crecimiento exponencial + crecimiento lineal anterior. El proceso de crecimiento. Además, el umbral también se ajustará en función del tamaño de la ventana de congestión actual.

La ventana de congestión es un proceso que cambia y se reajusta constantemente durante este proceso.

Estos ajustes pueden adaptarse bien a los entornos de red cambiantes.

Por supuesto, aquí también hay una gran pérdida de rendimiento.

Cada vez que vuelvo al inicio lento, la velocidad de transmisión se reducirá considerablemente.

Por lo tanto, detrás del control de la congestión nacieron algunos algoritmos de optimización (acortando el tiempo de ventana pequeña tanto como sea posible)

ventana real del remitente = min (ventana de congestión, ventana de control de flujo)

El control de congestión y el control de flujo limitan conjuntamente el mecanismo de ventana deslizante, lo que puede mejorar la eficiencia de la transmisión bajo la premisa de confiabilidad.

Mecanismo de respuesta retardada (eficiencia):

Es un mecanismo para mejorar la eficiencia de la transmisión.

¿Cómo aumentar el tamaño de la ventana tanto como sea posible si las condiciones lo permiten?

Es necesario retrasar un tiempo al devolver ACK. Con este tiempo de retraso, puede liberar más tiempo para que la aplicación consuma datos y el tiempo restante del búfer de recepción será mayor.

Si se devuelve ACK inmediatamente, el tamaño de la ventana de devolución es de 3 kb.

Pero después de esperar 500 ms, se devuelve ACK en este momento. Es posible que dentro de estos 500 ms, la aplicación haya consumido otros 2 kb. En este momento, el tamaño de la ventana devuelta es de 5 kb.

Aquí, cuánto se puede mejorar la velocidad retrasando la respuesta aún depende de las capacidades de procesamiento reales de la aplicación receptora.

Entonces, ¿se pueden responder todos los paquetes con retraso?

Límite de cantidad: responda una vez cada N paquetes (para ventana deslizante)

Límite de tiempo: responda una vez después del tiempo máximo de retraso (para ventanas no deslizantes)

La respuesta retrasada reduce el impacto de una transmisión confiable en la eficiencia de la transmisión

Mecanismo de respuesta a cuestas (eficiencia):

Sobre la base del retraso en la respuesta, se introduce un mecanismo para mejorar aún más la eficiencia.

La respuesta retrasada sirve para hacer que el tiempo de transmisión de ACK sea más lento, y la respuesta combinada sirve para permitir que los datos se fusionen en función de la respuesta retrasada.

La interacción entre el cliente y el servidor es en forma de preguntas y respuestas.

¿Por qué dice que cuatro ondas pueden ser tres veces?

Principalmente debido al efecto de la respuesta retardada y la respuesta a cuestas.

Los datagramas se fusionan de dos en uno y la eficiencia mejorará significativamente.

Principalmente porque cada vez que se transmiten datos aquí, es necesario encapsularlos y separarlos.

Razones para fusionarse:

Por un lado, la sincronización puede ser simultánea.

Por otro lado, los datos ACK en sí no necesitan llevar una carga útil y no entran en conflicto con los datos normales. Es completamente posible que este datagrama lleve tanto la carga útil como la información ACK (bit de bandera ACK, tamaño de ventana, confirmación). número de secuencia)

Orientado a flujos de bytes;

En el caso de flujo de bytes orientado, surgirán algunos problemas.

Problema de bolsa pegajosa:

"Adhesivo" aquí se refiere a "datagrama de capa de aplicación"

Los datos leídos/escritos a través de TCP son la carga útil de los paquetes de datos TCP, es decir, datos de la capa de aplicación.

El remitente puede enviar varios datagramas de capa de aplicación a la vez, pero al recibirlos, ¿cómo distinguir de dónde proviene un datagrama completo?

En otras palabras, si se envían dos paquetes, pero se leen como uno o un paquete y medio, surgirán problemas en este momento.

Aquí, el enfoque correcto es diseñar el protocolo de la capa de aplicación de manera razonable.

Este problema debe resolverse desde la perspectiva de la capa de aplicación.

1. En el protocolo de la capa de aplicación, se introducen delimitadores para distinguir los límites entre paquetes.

2. En el protocolo de la capa de aplicación, se introduce la "longitud del paquete" para distinguir los límites entre los paquetes.

1. Utilice \n como separador entre paquetes.

Puedes utilizar cualquier símbolo como delimitador, siempre y cuando te asegures de que el carácter del delimitador no existe en el mensaje oficial.

2. Utilice la longitud del paquete para distinguir

A través del proceso anterior, se completa el proceso general de lectura y análisis.

El problema de los paquetes adhesivos no solo es exclusivo de TCP, sino que también tiene el mismo problema siempre que sea un mecanismo (archivo) orientado al flujo de bytes.

La solución es la misma, use delimitadores o longitud.

Especialmente al personalizar los protocolos de la capa de aplicación, puede utilizar esta idea para resolver problemas.

Por el contrario, estas soluciones presentadas anteriormente:

xml/json se distinguen por delimitadores

El protobúfer se distingue por su longitud.

Manejo de excepciones TCP:

Habrá algunas variables en la propia red que harán que la conexión TCP no funcione correctamente.

1. Fallo del proceso

El proceso falla --> la PCB desapareció --> la tabla de descriptores de archivos se libera --> equivalente a llamar a socket.close() --> la parte que falló emitirá un FIN, lo que desencadenará cuatro ondas adicionales. tiempo La conexión se libera normalmente

soncket también es un archivo en el kernel del sistema y también se colocará en la tabla de descriptores de archivos.

En este momento, no hay diferencia entre el procesamiento TCP y la entrada y salida del proceso normal.

2. Apague el host (procedimiento de apagado normal)

El apagado normal primero intentará finalizar todos los procesos (intentar finalizar el proceso), que es lo mismo que el manejo de fallos que acabamos de mencionar.

El host tardará un cierto tiempo en apagarse. Dentro de este tiempo, las cuatro ondas pueden completarse (perfectamente). Si no, no importa.

3. El host está apagado (desenchufe la alimentación, no hay lugar para reaccionar)

La computadora de repente se apaga. Por supuesto, no hay espacio para operar en este momento. En este momento, A no puede enviar ningún FIN a B.

(1) Si B está enviando un mensaje a A (el receptor está apagado)

Esta situación es fácil de manejar. No habrá ACK para el mensaje enviado por B. B activará una retransmisión de tiempo de espera. Si la retransmisión aún falla, se activará un mensaje de reinicio (RST = 1). Intentará restablecer el conexión, pero la operación de reinicio aún falla. , la conexión continuará liberándose unilateralmente en este momento (B no tiene ningún impacto negativo)

(2) Si A está enviando un mensaje a B en este momento (el remitente está apagado)

Esta situación es un poco más complicada.

B está esperando un mensaje de A, y A repentinamente deja de enviar mensajes, B no sabe si A continuará enviando mensajes y B entrará en espera de bloqueo.

Se trata del "paquete de latidos del corazón".

Aunque B es el receptor, enviará periódicamente un datagrama TCP que no transporta ningún dato comercial (carga útil) a la otra parte.

El propósito de enviar este paquete es activar ACK, que es para confirmar si A está funcionando normalmente/confirmar si la red funciona sin problemas.

Si el lado A no puede devolver ACK correctamente, significa que el lado A está caído.

Los paquetes de latidos son lo mismo que los paquetes de detección de ventanas de "control de flujo" que mencionamos antes.

Aunque TCP ya tiene soporte para paquetes de latidos, no es suficiente. A menudo necesitamos volver a implementar paquetes de latidos en la capa de aplicación y en las aplicaciones (paquetes de latidos de TCP, el ciclo es demasiado largo).

4. El cable de red está desconectado.

Equivalente a una versión mejorada cuando el host se queda sin energía

A La situación enviada aquí es la primera situación en la que el host pierde energía.

La situación enviada aquí por B es la segunda situación en la que el anfitrión se queda sin energía.

Comparación de TCP y UDP

La ventaja de TCP es la confiabilidad, que es adecuada para la mayoría de escenarios.

La ventaja de UDP es la eficiencia, que es adecuada para la comunicación dentro de la sala de computadoras y entre hosts (dentro de la sala de computadoras, el ancho de banda es relativamente abundante, no es fácil encontrar congestión y pérdida de paquetes, y se espera que la comunicación entre hosts se más rápido)

Escenario típico: los juegos competitivos requieren una transmisión confiable y eficiente, en este caso ni TCP ni UDP son adecuados.

A veces también se utilizan otros protocolos más adecuados, como protocolos como KCP (otros llamados "protocolos de capa de transporte" realmente no funcionan en la capa de transporte, pero a menudo se implementan en la capa de aplicación de manera similar al mecanismo de la capa de transporte). Al mismo tiempo, en la parte inferior se basa en UDP para lograr una transmisión confiable)

3. Capa de red

(1) Número de versión de 4 dígitos: se utiliza para indicar la versión del protocolo IP

Sólo existen dos versiones del protocolo IP existente, IPv4 e IPv6. Es posible que otras versiones solo existan en laboratorios y no se hayan utilizado comercialmente a gran escala.

(2) Longitud del encabezado de 4 bits, la configuración es la misma que TCP

El encabezado IP puede ser largo y tiene opciones.

La unidad aquí también es de 4 bytes.

(3) tipo de servicio de 8 bits

(En realidad sólo 4 bits son efectivos)

Retraso mínimo: el tiempo para transmitir un datagrama es lo más corto posible

Rendimiento máximo: transfiera tantos datos como sea posible dentro de un período de tiempo determinado

Mayor confiabilidad: es menos probable que provoque la pérdida de paquetes durante la transmisión

Costo mínimo: los menores recursos de hardware consumidos durante el proceso de transmisión.

Los cuatro formularios son mutuamente excluyentes y sólo puedes cambiar a uno de ellos.

Aunque el protocolo IP admite este mecanismo, rara vez se aplica en el desarrollo y, por lo general, se trata de una personalización profunda a nivel del sistema.

(4) longitud total de 16 bits

Esta longitud se refiere a: encabezado IP + longitud de la carga útil

Longitud total: longitud del encabezado IP = longitud de la carga útil (longitud total del paquete TCP)

Longitud total del mensaje TCP - Longitud del encabezado TCP = Longitud de la carga útil TCP

La longitud total de 16 bits aquí implica la cuestión de 64 kb, pero el protocolo IP en sí admite el mecanismo de "desempaquetado y agrupación", y los 64 kb aquí solo restringen un datagrama IP.

Si es necesario transportar datos relativamente largos, el protocolo IP dividirá automáticamente un dato en varios datagramas y el receptor también fusionará varios datagramas en uno al dividirlos.

(5) Identificación de 16 bits, bit de identificación de 3 bits, desplazamiento de segmento de 13 bits

Estos tres describen todo el proceso de desempaquetado y empaquetado de datagramas IP.

Cuando un datagrama IP necesita transportar datos relativamente largos, la operación de descompresión se activa en la capa del protocolo IP.

Dividir un paquete en varios paquetes pequeños

Varios datagramas IP pequeños llevarán encabezados IP y la carga útil son varias partes del datagrama TCP.

Identificador de 16 bits: los identificadores de 16 bits de estos múltiples paquetes son los mismos.

Desplazamiento de segmento de 13 bits: Diferente, el desplazamiento de segmento del paquete anterior es menor y el del último es mayor. La secuencia de los paquetes se puede distinguir por el desplazamiento de segmento.

Bits de identificación de 3 dígitos: Uno de ellos no se utiliza, otro indica si se permite descomprimir y el restante indica la marca de fin (identificando si el paquete actual es el último)

(6) TTL con tiempo de vida de 8 bits

La unidad es veces

Inicialmente, TTL tendrá un valor (32/64/128)

Cada vez que se reenvía a través de un enrutador, el TTL será -1. Cuando TTL = 0, se descartará.

Normalmente. TTL es suficiente para soportar datagramas que llegan a cualquier ubicación de la red, si aparece 0, básicamente se puede considerar que la IP es inalcanzable.

(7) protocolo de 8 bits

Describe qué protocolo utiliza la capa superior, la capa de transporte.

(8) suma de comprobación del encabezado de 16 bits

Para verificar si los datos son correctos, solo necesita verificar el encabezado.

Debido a que la parte de la carga útil es TCP o UDP, ya lo verifiqué yo mismo.

(9) dirección de origen de 32 bits, dirección de destino de 32 bits

La parte más importante del protocolo IP.

Explicación detallada de los principios de la red (combinación de imágenes y texto)

1. Capa de aplicación

1. Solicitud y respuesta