Mensajería instantánea de iOS (2): Heartbeat Keep-Alive
Mucha gente cree que el protocolo TCP tiene un mecanismo KeepAlive. ¿Por qué los enlaces de comunicación basados en él todavía necesitan implementar latidos adicionales en la capa de aplicación? Este artículo le dirá desde la perspectiva de la mensajería instantánea móvil que incluso si se utiliza el protocolo TCP, el mantenimiento de los latidos en la capa de aplicación sigue siendo esencial.
En el diseño de servicios de mensajería instantánea que utilizan conexiones TCP largas, los latidos suelen estar involucrados. Heartbeat generalmente se refiere a que el cliente envía instrucciones personalizadas al servidor a ciertos intervalos para determinar si ambas partes están vivas. Debido a que se envía a ciertos intervalos, similar a un latido, se denomina instrucción de latido.
TCP es un protocolo basado en conexión y su estado de conexión es mantenido por una máquina de estado. Una vez completada la conexión (apretón de manos de tres vías), ambas partes estarán en el estado establecido y en el estado. no cambiará activamente después de eso. En otras palabras, incluso si la capa superior no realiza ninguna llamada y mantiene la conexión TCP inactiva, seguirá manteniendo el estado de la conexión. En este momento, se necesita un mecanismo para detectar el estado de la conexión TCP que surgió con esta misión.
Entonces la pregunta es: KeepAlive se usa para detectar el estado de la conexión TCP, entonces, ¿por qué se necesita un latido? Hay una situación que debe considerarse aquí: si un determinado servidor tiene una carga extremadamente alta por alguna razón, la CPU está al 100% y no puede responder a ninguna necesidad comercial, pero el estado de la conexión aún se puede determinar utilizando un TCP. probe Esta es una situación típica en la que la conexión está activa pero el negocio. Cuando el proveedor está muerto, la mejor opción para el cliente es desconectarse y volver a conectarse a otros servidores, en lugar de pensar siempre que el servidor actual está disponible y enviar solicitudes a. el servidor actual que inevitablemente fallará.
De lo anterior podemos saber que KeepAlive no es adecuado para detectar el escenario de supervivencia de ambas partes. Este escenario también depende del latido de la capa de aplicación. El latido de la capa de aplicación tiene mayor flexibilidad. Puede controlar el tiempo de detección, el intervalo y el flujo de procesamiento, e incluso puede adjuntar información adicional al paquete de latido. Desde esta perspectiva, el latido de la capa de aplicación es de hecho una mejor práctica.
TCP KeepAlive se utiliza para detectar la vida y la muerte de la conexión, y el mecanismo de latido viene con una función adicional: detectar el estado de supervivencia de ambas partes que se comunican.
De lo anterior podemos concluir que en la actualidad, el latido del corazón de la capa de aplicación es de hecho la mejor práctica para detectar la validez de la conexión y si ambas partes están vivas. Entonces el problema restante es cómo implementarlo.
El método más simple y básico es programar un latido. Por ejemplo, si se produce un latido cada 30 segundos y no se recibe un paquete de latido en 15 segundos, la conexión actual se considerará inválida y se desconectará. y volver a conectar. Este enfoque es el más directo y sencillo de implementar. El único problema es el consumo de energía y el consumo de datos. Calculado en base a los 5 bytes de un paquete de protocolo, se envían y reciben 2880 paquetes de latidos en un día, lo que equivale a 5 x 2 x 2880 x 30 = 0,8 M de tráfico en un mes. Si se instala más software de mensajería instantánea en el teléfono móvil, la cantidad de latidos por mes será de varios megabytes. El tráfico desaparecerá, sin mencionar el consumo de energía causado por los latidos frecuentes.
Dado que los latidos frecuentes traerán desventajas en el consumo de energía y el consumo de tráfico, la dirección natural de mejora es reducir la frecuencia de los latidos, pero no debería afectar demasiado el rendimiento en tiempo real de la detección de conexiones. Según este requisito, el intervalo de latidos generalmente se puede ajustar de acuerdo con el estado del programa. Cuando el programa está en segundo plano (aquí se refiere principalmente a Android), intente alargar el intervalo de latidos tanto como sea posible, 5 minutos o incluso 10 minutos. está bien.
Cuando la App está en primer plano, funciona según las reglas originales. El juicio de confiabilidad de la conexión también se puede relajar para evitar la situación en la que la conexión se considera inválida después de que se agote el tiempo de espera de un latido. La acumulación de errores se utiliza para determinar que la conexión actual no está disponible solo después de que se agote el tiempo de espera de n latidos.