[Uno de los principios de la red] Protocolo de capa de aplicación, protocolo de capa de transporte UDP y TCP, protocolo de enlace de tres vías TCP y onda de cuatro vías, y mecanismo de confiabilidad y eficiencia de TCP

protocolo de la capa de aplicación

En el servidor y el cliente TCP implementados, el protocolo de la capa de aplicación determinado por las partes emisoras es utilizar un carácter de nueva línea al final de cada mensaje. Es decir, se codifica según el carácter de nueva línea al enviar y se decodifica según el carácter de nueva línea al recibir. Al desarrollar un programa de aplicación, un gran trabajo es determinar el acuerdo. Los protocolos comunes de la capa de aplicación incluyen HTTP, FTP...

protocolo XML

Principalmente un formato para organizar datos. En el archivo XML, cada etiqueta aparece en pares y la etiqueta de cierre tiene una /. Si una etiqueta contiene subetiquetas, esta etiqueta puede representar un objeto. Si una etiqueta contiene varias subetiquetas idénticas, esta etiqueta representa una colección.

Desventajas: estructura compleja, antiestético, demasiados caracteres redundantes y la transmisión en la red consume más ancho de banda.

JSON

1. Utilice {} para representar un objeto,
2. Utilice [] para representar una colección,
3. Utilice "clave": "valor" para los atributos. Si el valor es un número entero, no se requieren comillas
4. Varios atributos están separados por comas y el último atributo no agrega una coma.

Las ventajas del formato JSON son la buena legibilidad, la belleza y la gran escalabilidad. La desventaja es que introduce caracteres adicionales y ocupa mucho ancho de banda.

HTTP

El protocolo HTTP se destacará en estudios posteriores.

protocolo de la capa de transporte

El protocolo central
UDP: sin conexión, transmisión no confiable, orientado a datagramas, dúplex completo, de tamaño limitado.
TCP: conexión, transmisión confiable, flujo de bytes orientado, dúplex completo, tamaño ilimitado.

protocolo UDP

Características de UDP

1. Sin conexión : el proceso de transmisión UDP es similar al envío de mensajes de texto. Si conoce la IP y el número de puerto del par, puede transmitir directamente sin establecer una conexión.
2. Transmisión no confiable : no existe un mecanismo de seguridad. Después de que el remitente envía el datagrama, si el segmento no se puede enviar a la otra parte debido a una falla en la red, la capa del protocolo UDP no devolverá ninguna información de error a la capa de la aplicación.
3. Orientado a datagramas : UDP enviará el mensaje a largo plazo enviado por la capa de aplicación a UDP tal como está, sin dividirlo ni fusionarlo.

Use UDP para transmitir 100 bytes de datos: si el remitente envía 100 bytes a la vez, entonces el receptor también debe recibir 100 bytes a la vez; en lugar de recibir 10 veces en un bucle, 10 bytes cada vez.

4. Búfer
• UDP solo tiene un búfer de recepción, no un búfer de envío
• UDP no tiene un búfer de envío real. Los datos enviados se entregarán directamente al kernel, y el kernel pasará los datos al protocolo de la 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 el orden de los mensajes UDP recibidos y el orden de los mensajes UDP enviados Consistente; si el búfer está lleno, los datos UDP entrantes se descartarán.
• Los sockets UDP pueden leer y escribir, este concepto se denomina dúplex completo.

5. Tamaño limitado:
hay una longitud máxima de 16 bits en el encabezado del protocolo UDP. Es decir, la longitud máxima de datos que puede transmitir un UDP es de 64K (incluida la cabecera UDP).

formato de protocolo UDP

UDP es un protocolo de capa de transporte, y el protocolo de capa de transporte se implementa a través del sistema operativo.El sistema operativo administra los procesos, y cada proceso abre un número de puerto. 16 bits pueden representar hasta 65535, lo que indica que el número de puerto oscila entre 0 y 65535. La longitud de UDP de 16 bits es de 65535 bytes, que es aproximadamente igual a 64 KB. La suma de verificación en UDP es una verificación de redundancia CRC. Es decir, el valor obtenido al acumular cada byte en los datos (matriz de bytes). Al analizar un mensaje UDP, los primeros 16 bits indican el puerto de origen y luego cortan 16 bits para identificar el número de puerto de destino.... La longitud final de datos interceptados está determinada por la longitud de UDP.

Ejemplo de acumulación de bytes:

public class Demo_CRC {
    
    
    public static void main(String[] args) throws UnsupportedEncodingException {
    
    
        // 定义两个字符串
//        String str = "你好世界";
        String str = "你好啊，一会去吃火锅吧！！！";
        String abc = "how are you.";
        // 转换成byte数组
        byte[] bytes = str.getBytes("UTF-8");
        System.out.println(Arrays.toString(bytes));
        System.out.println(bytes.length);

        // 循环累加每个byte的值，得到CRC结果
        int crc = 0;
        for (int i = 0; i < bytes.length; i++) {
    
    
            crc += bytes[i];
        }
        System.out.println("str crc = " + crc);

        // 转换成byte数组
        bytes = abc.getBytes("UTF-8");
        System.out.println(bytes.length);
        System.out.println(Arrays.toString(bytes));
        // 循环累加每个byte的值，得到CRC结果
        crc = 0;
        for (int i = 0; i < bytes.length; i++) {
    
    
            crc += bytes[i];
        }
        System.out.println("acb crc = " + crc);
    }
}

Protocolo TCP

Características de TCP

1 Conexión : el proceso de transmisión de TCP es similar a todos los aspectos de la llamada.
2 Transmisión confiable : a través de varios mecanismos de TCP para garantizar una transmisión confiable, 3-12 3.
Orientado a flujo de bytes : el contenido se envía en bytes y se recibe
4. Búfer : TCP tiene un búfer de recepción y un búfer de envío. duplex completo.
5. Tamaño ilimitado .

formato de protocolo TCP

Los puertos de origen y destino de 16 bits son los mismos que en UDP y se utilizan para identificar procesos.
Longitud del encabezado de 4 bits : 1111 = 15. El encabezado puede tener un total de 15*4 bytes = 60 bytes. La opción anterior tiene 4 * 5 = 20 bytes, por lo que la opción tiene un máximo de 40 bytes.
Los datos son la carga enviada por la capa de aplicación.
Six flags : 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 un segmento de sincronización . FIN: Informar a la otra parte que el extremo local se va a cerrar, llamamos al segmento final que lleva la bandera FIN .
Suma de verificación de 16 bits : suma de verificación CRC.
Las opciones son mensajes personalizados.
Puntero urgente de 16 bits : identifica qué parte de los datos son datos urgentes, que no se trata por el momento.
El número de secuencia, el número de secuencia de confirmación y el tamaño de la ventana se presentarán más adelante.

Mecanismo de Seguridad y Eficiencia de TCP

Respuesta de acuse de recibo (mecanismo fiable)

En el proceso de chatear con personas, el proceso de envío y recepción es la respuesta de confirmación. Por razones de red, puede haber un problema de envío y recepción de información fuera de servicio. Para resolver este problema, TCP numera cada byte de datos. es el número de serie.

Este número de secuencia se almacena en el número de secuencia de 32 bits y el número de secuencia de confirmación de 32 bits mencionados anteriormente. Para enviar y recibir datos, TCP proporciona SYN (envío) y ACK (respuesta) para marcar. El ACK lleva el número de secuencia de confirmación , que es para decirle al remitente dónde lo he recibido y dónde desea comenzar a enviarlo la próxima vez. Al enviar una solicitud, configure el indicador SYN en 1 y configure el indicador ACK en 1 al responder.

Retransmisión de tiempo de espera (mecanismo confiable)

En el proceso de transmisión en la red, el mensaje pasará a través del sistema operativo, la tarjeta de red, el conmutador, el enrutador y otros dispositivos de red. Cada dispositivo tiene su propia capacidad de carga, si excede el rango, el paquete de datos actual puede ser bloqueado o descartado.

1. El remitente pierde paquetes

Después de esperar un momento y descubrir que no se ha recibido el ACK, vuelva a enviar los datos anteriores después del tiempo especificado.

2. Tiempo de espera de respuesta

El host B recibió los datos y envió una respuesta ACK, pero el host A simplemente no recibió la respuesta. En este caso habrá un problema de recepción duplicada . En este momento, el host B filtra los datos duplicados a través de un número de secuencia de reconocimiento de 32 bits en su propio búfer. Y dar directamente la respuesta ACK.

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

• Lo ideal es encontrar un tiempo mínimo para garantizar que "la respuesta de confirmación debe ser devuelta 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; • TCP es para garantizar una comunicación de alto rendimiento en cualquier entorno, por lo que el período de tiempo de espera
máximo será calculado dinámicamente. En Linux (lo mismo ocurre con 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 500 ms antes de retransmitir. Si aún no hay respuesta, espere 4 500 ms para la retransmisión. 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 y cierra la conexión a la fuerza.

Gestión de conexiones (mecanismo fiable)

Cuando los hosts se comunican en la red como emisores y receptores, deben confirmar la capacidad de ambas partes para enviar y recibir datos, lo que implica el proceso de negociación de establecimiento y desconexión de conexiones. Todos los días antes del primer tren del tren de alta velocidad, funcionará vacío.Para la comunicación de la red, es para verificar las capacidades de las partes emisoras y receptoras .

Apretón de manos de tres vías (proceso de conexión)

A través del proceso de SYN y ACK dos veces, se puede garantizar que no hay problema con las redes de ambas partes. Sobre esta base, se puede llevar a cabo la transmisión y recepción normal de datos. El propio TCP optimiza la eficiencia y combina SYN+ACK en una sola operación, que es el protocolo de enlace de tres vías .

Los dos apretones de manos no se pueden usar para confirmar las capacidades de envío y recepción de ambas partes, porque no hay una verificación completa. Cuatro veces está bien, simplemente desmonte SYN+ACK.

Otra función importante del protocolo de enlace de tres vías es negociar dónde comienza el número de serie .

estado del puerto

Verifique el puerto a través del comando netstat-an:

Ondulado cuatro veces (proceso desconectado)

El primer ACK es la respuesta del protocolo TCP implementado por el sistema operativo, y el segundo FIN es a nivel de aplicación. Hay una diferencia de tiempo entre estas dos operaciones, y existe una alta probabilidad de que no se fusionen y se devuelvan juntas , por lo que se describe como cuatro manos agitadas. ¿Cómo lidiar con la pérdida del segundo paquete FIN? Si el paquete se pierde, activará una retransmisión por tiempo de espera.

transición de estado

Servidor:

[CLOSED -> LISTEN]Después de que el servidor llama a escuchar, ingresa al estado LISTEN y espera a que el cliente se conecte;
[LISTEN -> SYN_RCVD]una vez que monitorea la solicitud de conexión (segmento de sincronización), coloca la conexión en la cola de espera del kernel y envía un mensaje de confirmación SYN al cliente.
[SYN_RCVD -> ESTABLISHED]Una vez que el servidor recibe el mensaje de confirmación del cliente, ingresa al estado ESTABLECIDO y puede leer y escribir datos.
[ESTABLISHED -> CLOSE_WAIT]Cuando el cliente cierra activamente la conexión (calling close), el servidor recibirá el segmento del mensaje final, el servidor devuelve el segmento del mensaje de confirmación e ingresa CLOSE_WAIT; después de ingresar CLOSE_WAIT, indica que el servidor está listo para cerrar la conexión (el
[CLOSE_WAIT -> LAST_ACK]anterior datos necesitan ser procesados); cuando el servidor realmente Cuando se llama a close para cerrar la conexión, se enviará un FIN al cliente. En este momento, el servidor entra en el estado LAST_ACK y espera a que llegue el último ACK (este ACK es la confirmación del cliente de que ha recibido el FIN). Si hay una gran cantidad de estados CLOSE_WAIT en el sistema, es posible que el programa no haya llamado al método close().
[LAST_ACK -> CLOSED]El servidor recibe el ACK to FIN y cierra completamente la conexión. Después de Cerrar, esperará a que el sistema recupere los recursos.

cliente:

[CLOSED -> SYN_SENT]El cliente llama a connect para enviar un segmento síncrono;
[SYN_SENT -> ESTABLISHED]si la llamada de conexión tiene éxito, ingresa al estado ESTABLECIDO y comienza a leer y escribir datos;
[ESTABLISHED -> FIN_WAIT_1]cuando el cliente llama activamente a close, envía el segmento final al servidor e ingresa FIN_WAIT_1 al mismo tiempo time
[FIN_WAIT_1 -> FIN_WAIT_2]; Después de la confirmación del segmento final, ingrese FIN_WAIT_2 y comience 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; el cliente debe
[TIME_WAIT -> CLOSED]espere Un tiempo de 2MSL (vida máxima del segmento, vida útil máxima del mensaje) entrará en el estado CERRADO.

Ventana corredera (mecanismo de eficiencia)

El proceso de envío y recepción de datos puede garantizar una comunicación normal, pero la eficiencia no es alta. Dado que el rendimiento de este método de envío y recepción es bajo, enviamos varios datos a la vez , como se muestra en la figura:

1. Diagrama
• La ventana deslizante en sí es una estructura de datos utilizada para mantener el tamaño de la ventana y los datos que se han enviado y se están enviando.
• Los datos en el cuadro blanco son el segmento de datos que espera ACK.
• 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, envía directamente sin esperar ningún ACK;
• Después de recibir el primer ACK, la ventana deslizante se mueve hacia atrás y continúa enviando los datos del quinto segmento; y así sucesivamente
; Para mantener esta ventana deslizante, se es necesario crear un búfer de envío para registrar qué datos están actualmente sin responder, solo los datos que han sido confirmados y respondidos pueden ser eliminados del búfer •
Cuanto mayor sea la ventana, mayor será el rendimiento de la red;

2. Problema de pérdida de paquetes predecible

La respuesta ACK se pierde:

Incluso si se pierde un cierto ACK en el medio, el número de secuencia de confirmación en la última respuesta de ACK indica que se han recibido todos los paquetes de datos anteriores.

Solicitud SYN perdida:

En el proceso de recepción de datos, si se encuentra que falta parte del número de secuencia de 32 bits, se enviará ACK todo el tiempo para solicitar al remitente la parte faltante de los datos. En este momento, otros datos recibidos se almacenarán en caché y los datos faltantes se reunirán después de que se completen los datos.

3. Eficiencia de la ventana corredera

La eficiencia depende del tamaño de la ventana;
cuanto mayor sea la ventana, mayor será la eficiencia;
cuanto más pequeña sea la ventana, menor será la eficiencia;
asumiendo que la ventana es infinita, el remitente no necesita esperar por ACK en absoluto, y la eficiencia es la misma que UDP.

control de flujo (mecanismo confiable)

La eficiencia de la ventana corrediza se menciona arriba, entonces, ¿qué tan grande es la ventana corrediza? El control de flujo confirma principalmente el tamaño de la ventana deslizante, que se confirma a través de la negociación dinámica entre el emisor y el receptor. Por ejemplo, después de cocinar, pregunta cuánto puedes comer y te daré todo el arroz que quieras.

1. Búfer de envío y recepción

Cada programa solicitará los recursos del sistema cuando se inicie, y los búferes de envío y recepción son los recursos solicitados, es decir, un área en la memoria utilizada para almacenar flujos de datos BYTE. ACK llena el campo de protocolo de tamaño de ventana (tamaño de ventana de 16 bits) con el tamaño del espacio restante en el búfer. El receptor contrarresta el límite del remitente en el tamaño de la ventana, y el remitente no puede expandir el tamaño de la ventana sin límite para mejorar la eficiencia. El tamaño del espacio utilizado y el espacio restante es dinámico, y cada vez que el receptor lee datos del búfer, el espacio restante será más grande.

2. Proceso específico

• El remitente envía datos al receptor;
• Después de recibir los datos, el receptor almacena los datos en el búfer del receptor (un espacio abierto en la memoria); • La
aplicación del receptor lee del búfer a través del socket api (lnputStream) Al leer datos , los datos en el búfer serán menores, lo que equivale a enviar el espacio restante del búfer al remitente cuando el receptor de los datos recibe un ACK; • El tamaño del espacio restante es equivalente a El extremo receptor pone el tamaño del
búfer puede recibir en el "campo de tamaño de ventana" en el encabezado TCP, y notifica al extremo de envío a través de ACK; • Cuanto mayor sea el campo de tamaño de ventana, mayor será el rendimiento de la red. Recibir Una vez que el extremo encuentra que su búfer está casi
lleno , configurará el tamaño de la ventana a un valor más pequeño y notificará al remitente; •
Después de recibir la ventana, el remitente disminuirá su velocidad de envío. Cuando esté llena, la ventana se establecerá en 0; en este momento, el remitente ya no enviará datos, pero necesita enviar periódicamente un segmento de datos de detección de ventana, para que el receptor pueda decirle al remitente el tamaño de la ventana.

Si el lado receptor tiene poca potencia de procesamiento, es posible que el búfer se llene. En este momento, el emisor enviará una solicitud de detección de ventana cada cierto tiempo , sin datos reales, y le preguntará al receptor cuánto más puede recibir.

3. Tamaño real de la ventana

En el encabezado TCP, hay un campo de ventana de 16 bits que almacena la información del tamaño de la ventana. El valor máximo de 16 dígitos es 65535, entonces, ¿la ventana TCP máxima es de 65535 bytes? De hecho, la opción de 40 bytes en el 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 .

Control de congestión (mecanismo confiable)

El proceso de transmisión de datos en la red es muy complicado y puede pasar a través de muchos dispositivos de red, como conmutadores y enrutadores. Un problema con cada dispositivo de red afectará la transmisión.

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 qué tan rápido transmitir los datos.
Un concepto introducido aquí se llama la ventana de congestión .

1. Al comienzo del envío, el tamaño de la ventana de congestión se define como 1. Cada vez que se recibe una respuesta ACK, la ventana de congestión aumenta en 1. 2. Cada vez que se envían datos a
continuación, el tamaño de la ventana se expande exponencialmente en 2. 4 8 16
3. Cuando alcanza En el umbral inicial, ya no se expande exponencialmente, sino que aumenta linealmente, sumando 1 cada vez
4. Cuando la ventana alcanza un cierto valor, se produce una gran cantidad de pérdida de paquetes, es decir digamos, se producen frecuentes retransmisiones de tiempo de espera, lo que significa que la red está congestionada
5. El tamaño de la ventana de congestión vuelve directamente al valor mínimo de 1, y el nuevo umbral de la ventana de congestión también se ajustará a la mitad de la congestión actual ventana
6. Repita los pasos 1-5.
Cada vez que se envía un paquete de datos, la ventana de congestión se compara con el tamaño del búfer del extremo receptor y el valor más pequeño se toma como la ventana de envío real .

Una pequeña cantidad de pérdida de paquetes solo activa la retransmisión por tiempo de espera; una gran cantidad de pérdida de paquetes significa que la red está congestionada; cuando se inicia la comunicación TCP, el rendimiento de la red aumentará gradualmente; a medida que la red se congestione, el rendimiento disminuirá inmediatamente; control de congestión , En el análisis final, el protocolo TCP quiere transmitir datos a la otra parte lo más rápido posible, pero también necesita evitar un compromiso que cause demasiada presión en la red.

Respuesta retardada (mecanismo de eficiencia)

En el proceso de envío y recepción, el receptor procesa constantemente datos, y la parte no utilizada del búfer del receptor aumenta constantemente. Al retrasar la respuesta, se puede devolver al remitente el último tamaño no utilizado del búfer, lo que aumenta el tamaño de la ventana y mejora la eficiencia del envío y la recepción de la red .

1. Respuesta de intervalo: el número de intervalos es generalmente 2. Es decir, no necesariamente responde todas las veces, sino que una vez recibe dos solicitudes y responde una vez. Por ejemplo, 2 4 6 8 respuestas. Pero si todo el proceso de envío finaliza después de solo 3 veces, no debería haber forma de devolver ACK debido a la demora.
2. Límite de tiempo: responda una vez cuando se exceda el tiempo máximo de demora. El sistema tiene un valor por defecto, generalmente 200ms, que se puede modificar.

Piggybacking (mecanismo de eficiencia)

Normalmente, cuando el receptor recibe una solicitud SYN, el kernel del sistema responderá inmediatamente con un ACK. La respuesta real la realiza el programa de aplicación, y hay una cierta diferencia de tiempo con respecto al momento del ACK. Debido a la existencia de una respuesta demorada, puede haber una situación en la que el mensaje SYN y el mensaje ACK se envíen al mismo tiempo , luego el sistema combinará los dos mensajes en uno. Este mecanismo se llama ligeramente sensible.

Nota: Aunque hay un mecanismo de respuesta leve, no sucede el 100 % de las veces. Esto lo maneja el kernel del sistema.

orientado a la corriente

Dado que el receptor colocará los datos enviados por el remitente en el búfer del receptor, y el búfer del receptor es una matriz de BYTE, no puede distinguir efectivamente el límite del mensaje.Este fenómeno se denomina problema del paquete pegajoso.

Resuelva el problema del paquete pegajoso:

1. Agregue un delimitador especial al final del mensaje para marcar el final del mensaje, cuando lo use, simplemente intercepte el contenido del búfer de acuerdo con el carácter especial.
2. Utilice un campo especialmente utilizado para describir la longitud del cuerpo del mensaje para identificar la longitud específica del cuerpo del mensaje.

Antes de leer el mensaje, primero lea el contenido del campo de 4 bytes que indica la longitud del cuerpo del mensaje y el valor es 42;
continúe leyendo 42 bytes en el búfer, y estos 42 bytes representan el contenido del mensaje;
luego lea 4 bytes Indica la longitud del siguiente mensaje, ..., simplemente ejecútelo repetidamente.

JSON usa llaves para envolver mensajes, por lo que se puede entender que usa llaves como caracteres especiales para indicar el final del mensaje.
HTTP, el protocolo de la capa de aplicación, utiliza un campo que indica la longitud del mensaje, incluso si se utiliza el delimitador para resolver el problema de los paquetes pegajosos.

Manejo de excepciones de TCP

1. Bloqueo del programa : el sistema operativo lo percibirá y lo manejará en consecuencia. El sistema operativo recuperará los recursos del proceso, incluida la liberación del descriptor de archivo, que es equivalente a llamar al cierre del socket correspondiente, y luego activa la operación FIN, y luego comienza a ingresar la onda de cuatro ondas, que no es diferente de la onda ordinaria de cuatro ondas.
2. Apagado normal : a través del menú de inicio o ejecutando el comando de apagado, el sistema finalizará todos los procesos y reciclará los recursos a la fuerza, lo cual es similar al proceso de ejecución de bloqueo del programa.
3. Fallo de alimentación del host : el sistema operativo no responderá.
El receptor está apagado: el remitente no sabe que el receptor está colgado y continúa enviando datos y no recibe una respuesta ACK después de enviar los datos, lo que activa una retransmisión de tiempo de espera para múltiples retransmisiones sin recibir una respuesta ACK, y intente restablecer la conexión (bandera RST) el restablecimiento de la conexión también falla y la conexión solo se puede abandonar.
Falla de energía del remitente: generalmente ocurre en una conexión larga, el servidor y el cliente mantendrán un paquete de latidos (el cliente envía un paquete de datos al servidor cada 1 segundo para demostrar que está vivo si el servidor no ha recibido el latido paquete, como over Si no lo ha recibido después de 10 segundos, se considera que el cliente está colgado, y puede desconectar la conexión usted mismo y volver a conectarse después de que la red del cliente se recupere. El host funciona
normalmente .

---

sigue así~