¿Por qué necesitas un mecanismo de latido del corazón?
El enfoque de "conexión larga" nos ha traído muchos beneficios. El enlace más importante para lograr una entrega confiable de mensajes a través de la "conexión larga" es cómo mantener esta "conexión larga". Dado que la conexión TCP utilizada en la parte inferior de esta "conexión persistente" no es una conexión física real, en realidad es solo una conexión virtual imperceptible. Los extremos desconectados del enlace intermedio no lo notarán, así que mantenga esto " Una cuestión clave de la "conexión larga" es permitir que esta "conexión larga" sea notificada rápidamente cuando haya un problema con el enlace intermedio y luego restablecer una nueva conexión disponible mediante "reconexión", de modo que Nuestra "conexión larga" siempre ha mantenido un estado de "alta disponibilidad".
Este mecanismo para identificar la disponibilidad de la conexión "rápida" e "ininterrumpida" se denomina "mecanismo de latido". El "mecanismo de latido" prueba la disponibilidad de la conexión enviando continuamente "datos simulados" a la conexión, y al mismo tiempo permite que nuestra conexión continúe teniendo flujo de datos cuando no hay datos comerciales reales para enviar y recibir, sin ser operada por la red intermedia. La empresa piensa que la conexión ya no está en uso y corta la conexión.
1. Reducir la sobrecarga del mantenimiento de la conexión del servidor
Para la mayoría de los escenarios de mensajería instantánea, ambas partes envían y reciben mensajes a menudo en un entorno de red móvil. Los cambios en la intensidad de las señales de los teléfonos móviles y las fallas de enrutamiento intermedio pueden hacer que la "conexión larga" no esté realmente disponible.
Por ejemplo, si el usuario entra al ascensor con un teléfono móvil, la señal de la red del teléfono móvil desaparece repentinamente por completo. La conexión larga ya no está disponible en este momento, pero el servidor de mensajería instantánea no puede percibir esta situación de "conexión no disponible"; además, si nuestro enrutador de Internet de repente La conexión se interrumpe La larga conexión establecida entre la aplicación y el servidor de mensajería instantánea se encuentra en realidad en un estado no disponible en este momento, pero el cliente y el servidor de mensajería instantánea tampoco pueden percibirla. El "servidor push" de mensajes se puede realizar porque mantenemos la relación de mapeo correspondiente entre "equipo de usuario" y "conexión de red" en el servidor de mensajería instantánea para cada dispositivo que se conecta. Además, En muchos casos, para ahorrar la sobrecarga de la red, cierta información del cliente (como el número de versión de la aplicación, el sistema operativo, el estado de la red, etc.) que no es necesario llevar en cada solicitud se almacena temporalmente en el servidor, de modo que una vez que el cliente ha establecido una conexión larga , Solo necesita llevar esta información por primera vez, y las solicitudes posteriores no necesitan volver a llevarla, sino utilizar la información almacenada en caché por el servidor de MI. Además, en la implementación de muchos mensajes instantáneos, cierta información sobre el "estado del usuario en línea" y "todos los dispositivos en línea" se mantendrá en el lado del servidor, lo que es conveniente para el uso comercial.
Si el servidor de mensajería instantánea no puede percibir las condiciones anormales de estas conexiones, se producirá un problema: el servidor de mensajería instantánea puede mantener una gran cantidad de "conexiones no válidas", lo que conduce a un grave desperdicio de recursos de control de conexión; también almacena en caché una gran cantidad de La información como "relación de mapeo", "información del dispositivo" y "estado en línea" que ya no son útiles en lo anterior también es un desperdicio de recursos. Además, el servidor de MI envía mensajes a "conexiones largas no válidas" y se reducirán los reintentos posteriores El rendimiento general del servicio.
2. Admite la reconexión del cliente después de la desconexión
Mediante el "latido" para identificar rápidamente la disponibilidad de la conexión, además de reducir la sobrecarga de recursos del servidor, también se utiliza para soportar el mecanismo de desconexión y reconexión del cliente. Para que el cliente envíe un paquete de latidos, si dentro de un cierto período de tiempo de espera (considerando el cierto retraso de la transmisión de la red, el período de tiempo de espera debe ser al menos mayor que un intervalo de latido), por ejemplo, si el paquete de latidos se envía dos veces seguidas, no se recibe ningún mensaje instantáneo. Si el servidor responde, el cliente puede pensar que la conexión larga con el servidor no está disponible y el cliente puede desconectarse y volver a conectarse. La causa de que el servidor no responda puede ser que la red con el servidor esté desconectada en el medio o que la carga del servidor sea demasiado alta para responder a los paquetes de latidos. No importa cuál sea la situación, es necesario volver a conectarse después de la desconexión en este escenario. Permite al cliente mantener rápida y automáticamente la disponibilidad de la conexión.
3. Conectar Keep Alive
Para mantener una conexión larga "altamente disponible", otra tarea importante es intentar hacer que la conexión larga establecida sobreviva más tiempo.
Aquí puede preguntar: ¿Se puede interrumpir la conexión larga cuando la red del usuario y la red de enrutamiento intermedia son normales? La respuesta es: lo hace.
Para explorar esta razón, puedo comenzar con IPv4. Debido a los recursos limitados de IP pública IPv4 (aproximadamente 4,3 mil millones), para ahorrar el uso de IP pública, a los teléfonos móviles conectados a Internet a través de operadores móviles solo se les asigna una IP desde la intranet del operador.
Al acceder a Internet, la puerta de enlace del operador utiliza una tabla de asignación bidireccional desde "IP y puerto de red externa" a "IP y puerto de intranet" para permitir que los teléfonos móviles que realmente usan IP de red interna se comuniquen con redes externas. Esta conversión de dirección de red El proceso se denomina NAT (traducción de direcciones de red).
No hay nada de malo en el mecanismo de implementación de NAT en sí. El problema es que muchos operadores, para ahorrar recursos y reducir la presión en sus propias pasarelas, para conexiones que no se han enviado o recibido durante un período de tiempo, los operadores las eliminarán de la tabla de mapeo de NAT, y esta eliminación Las acciones no serán percibidas por el teléfono móvil y el servidor de mensajería instantánea. En este caso, si no existe una relación de mapeo NAT, el envío y la recepción de mensajes en la conexión persistente no se puede realizar normalmente. Y cuánto tiempo tomará borrar la tabla de mapeo de NAT, los operadores en cada lugar también son diferentes, desde unos pocos minutos hasta unas pocas horas. Suponiendo que el usuario no ha enviado ni recibido mensajes durante unos minutos, es posible que la conexión larga no haya estado disponible. Entonces, si nuestro cliente puede enviar alguna señalización al servidor durante el tiempo libre cuando no hay envío ni recepción de mensajes, puede evitar que la conexión larga sea eliminada por el operador NAT. Estas "señales" generalmente se implementan a través de paquetes de latidos.
Varios métodos de implementación de detección de latidos
Actualmente, existen tres métodos de implementación de uso común en la industria: TCP Keepalive, Application Layer Heartbeat y Smart Heartbeat.
1.TCP Keepalive
TCP Keepalive es parte de la implementación de la pila de protocolos TCP / IP del sistema operativo. Para la conexión TCP local, enviará automáticamente paquetes de detección sin datos a una cierta frecuencia durante el período inactivo de la conexión para detectar si la otra parte está viva. El sistema operativo desactiva esta función de forma predeterminada y la capa de aplicación debe activarla. Los tres elementos de configuración predeterminados: el período de latido es de 2 horas, 9 veces después de la falla y el período de tiempo de espera es de 75 segundos. Los tres elementos de configuración se pueden ajustar.
Desde este punto de vista, como una implementación existente de la pila de protocolos TCP / IP de la capa del sistema, Keepalive de TCP no requiere otra carga de trabajo de desarrollo. Es muy conveniente de usar como un mecanismo de detección para la supervivencia de la conexión; las aplicaciones de la capa superior solo necesitan procesar lo detectado La conexión es anormal, el paquete de latidos no transporta datos y el desperdicio de recursos de ancho de banda es mínimo. Debido a las ventajas de facilidad de uso y bajo consumo de red, los Keepalives de TCP están habilitados en muchos sistemas de mensajería instantánea. En la captura de paquetes anterior se encontró que WhatsApps usa Keepalives de TCP con un período de inactividad de 10 segundos para la detección de supervivencia. Aunque tiene muchas ventajas, TCP Keepalive en sí mismo tiene algunas deficiencias. Por ejemplo, la flexibilidad del intervalo de latidos es pobre. Un servidor solo se puede ajustar a un intervalo fijo de latidos en un momento determinado; además, TCP Keepalive puede usarse para detectar la supervivencia de la capa de conexión. , Pero no significa que la capa de aplicación real esté disponible.
Desventajas: Permítanme dar un ejemplo. Por ejemplo, cuando el sistema de mensajería instantánea tiene un bloqueo o bloqueo de código, ya no puede procesar solicitudes comerciales. Pero en este momento, la sonda TCP Keepalive de la capa de conexión no requiere la participación de la capa de aplicación y aún puede estar en la capa del kernel. Respuesta normal. Esta situación dará lugar a errores de juicio en la detección y evitará que las máquinas que han perdido la capacidad de procesamiento empresarial se descubran a tiempo.
2. Latido de la capa de aplicación
Para resolver algunas de las deficiencias de TCP Keepalive, muchos servicios de mensajería instantánea utilizan el pulso de la capa de aplicación para mejorar la flexibilidad y precisión de la detección. El latido de la capa de aplicación en realidad significa que el cliente envía un paquete de datos de la capa empresarial al servidor de mensajería instantánea a intervalos regulares para informarse de su supervivencia. Si el servidor de mensajería instantánea no recibe el paquete de latidos dentro de un cierto período de tiempo, se determina que la conexión del cliente es inaccesible por algún motivo, y la conexión se desconecta del servidor de mensajería instantánea al mismo tiempo, y otros recursos asignados en consecuencia se borran.
En comparación con el latido de TCP Keepalive, el latido de la capa de aplicación no pertenece a la implementación de la pila del protocolo TCP / IP, por lo que habrá una sobrecarga adicional de transmisión de datos. Sin embargo, los paquetes de latido de la mayoría de los latidos de la capa de aplicación están diseñados para ser lo más simples posible, generalmente solo unos pocos Bytes, por ejemplo, algunos paquetes de latidos de la capa de aplicación son solo un paquete vacío para mantener vivo, y algunos paquetes de latidos solo llevan el intervalo de latidos para que el cliente ajuste el siguiente latido, por lo que la sobrecarga de datos adicionales es muy pequeña. En comparación con TCP Keepalive, el latido de la capa de aplicación necesita procesar el envío y la recepción en la capa de aplicación, por lo que puede reflejar mejor la disponibilidad de la aplicación, en lugar de simplemente representar la disponibilidad de la red. Además, el latido de la capa de aplicación puede establecer de manera flexible el intervalo de latido de acuerdo con las condiciones reales de la red. En la situación real del caos de tiempo de espera de NAT de los operadores domésticos, el intervalo de latido configurado de manera flexible tiene ventajas más obvias para ahorrar tráfico de red y mantenerse vivo.
En la actualidad, la mayoría de los IM utilizan soluciones de latido de la capa de aplicación para resolver los problemas de mantenimiento de la conexión y detección de disponibilidad. Por ejemplo, en la captura de paquetes anterior, se encontró que el intervalo de latido de la capa de aplicación de WhatApps es de 30 segundos y 1 minuto. El intervalo de latido de la capa de aplicación de WeChat es principalmente de 4 minutos y medio. En la actualidad, la conexión larga de microblog utiliza un intervalo de latido de 2 minutos. Cada cliente de mensajería instantánea envía una estrategia de latido de manera diferente. La más simple es enviar paquetes de latido a una frecuencia fija, independientemente de si la conexión está inactiva o no. Antes de tomar el paquete QQ del teléfono móvil, descubrí que la aplicación enviará un latido a una frecuencia de aproximadamente 45 s; también hay una estrategia un poco más complicada en la que el cliente envía un paquete de latido después de que los datos están inactivos. Esta comparación es mejor para ahorrar tráfico, pero se ha realizado Lo anterior es un poco más complicado.
El siguiente es un diagrama de flujo típico de procesamiento de latidos de la capa de aplicación del cliente y el servidor. Se puede ver en la figura que el cliente y el servidor utilizan cada uno el mecanismo de latidos para lograr una "reconexión desconectada" y una "limpieza de recursos".
Cabe señalar que para el cliente, el tiempo para determinar si la conexión está inactiva es el tiempo de intervalo de latido establecido, mientras que para el servidor, considerando el retraso en la transmisión de datos de la red, el tiempo de espera para determinar si la conexión está inactiva requiere Es mayor que el intervalo de latidos, para evitar un juicio erróneo de la disponibilidad de la conexión debido al retraso de transmisión de la red . Latido inteligente
3. Latido inteligente
En el escenario de la red móvil doméstica, el tiempo de espera de NAT varía mucho entre los operadores locales bajo diferentes tipos de red. Aunque la implementación del latido de la capa de aplicación de frecuencia fija es relativamente simple, para evitar el tiempo de espera de NAT, el intervalo de latido solo se puede configurar para que sea menor que el tiempo de espera de NAT más corto en todos los entornos de red. Aunque también puede resolver el problema, pero para la CPU del dispositivo, Los recursos de energía y tráfico de la red no se pueden ahorrar en la mayor medida. Para optimizar este fenómeno, muchos escenarios de mensajería instantánea adoptarán la solución de "latido inteligente" para equilibrar el "tiempo de espera de NAT" y el "ahorro de recursos del dispositivo". El llamado latido inteligente significa que el intervalo de latido se puede ajustar automáticamente de acuerdo con el entorno de la red. Al ajustar continuamente el intervalo de latido, el punto crítico de tiempo de espera de NAT se acerca gradualmente y los recursos del equipo se guardan tanto como sea posible mientras se asegura que el NAT no se agote. Se dice que WeChat ha adoptado una solución inteligente de latidos para optimizar el intervalo de latidos. Sin embargo, desde un punto de vista personal, con la drástica reducción actual de las tarifas móviles, las condiciones de los equipos de hardware de los teléfonos móviles son cada vez mejores, y los latidos inteligentes tienen un efecto limitado en el ahorro de recursos del equipo. Además, la solución de latido inteligente debe seguir intentándolo en el proceso de confirmar el punto crítico del tiempo de espera de NAT, lo que también puede reducir la disponibilidad de la conexión de la "fase de confirmación de tiempo de espera" hasta cierto punto. Por lo tanto, le sugiero que evalúe las necesidades de sus propios escenarios comerciales. necesidad.
para resumir:
El "mecanismo de latido" establecido por el cliente y el servidor de mensajería instantánea puede identificar rápida y automáticamente si la conexión está disponible y, al mismo tiempo, evitar que el operador se desconecte debido al tiempo de espera de NAT. El "mecanismo de latido" resuelve los siguientes tres problemas:
1. Reducir la sobrecarga de mantenimiento de la conexión del servidor conexión no válida.
2. Ayude al cliente a identificar rápidamente conexiones no válidas y a desconectarse y reconectarse automáticamente.
3. Mantenga la conexión viva para evitar ser desconectado por el operador NAT horas extras.
La realización de la detección de latidos adopta principalmente los dos métodos siguientes en la industria:
1. TCP Keepalive. La pila de protocolos TCP / IP del sistema operativo viene con ella, no se requiere desarrollo secundario, es fácil de usar, no transporta datos y consume menos tráfico de red. Sin embargo, existen defectos como flexibilidad insuficiente e incapacidad para determinar si la capa de aplicación está disponible.
2. Latido de la capa de aplicación. La aplicación del mecanismo de latido por sí solo requiere una cierta cantidad de desarrollo de código, y el consumo de tráfico de red es un poco mayor, pero la flexibilidad del intervalo de latido es buena y con el mecanismo de latido inteligente, puede lograr el máximo ahorro de consumo de recursos del equipo sin tiempo de espera de NAT. "Al mismo tiempo, puede retroalimentar con mayor precisión la verdadera disponibilidad de la capa de aplicación.