1. Introducción
Debido a la complejidad de las redes móviles, es muy difícil escribir aplicaciones móviles de alta calidad y experiencia con capacidades de comunicación de red (especialmente aplicaciones con calidad de red altamente sensible como la mensajería instantánea).
La red móvil que generalmente vemos tiene las siguientes tres características típicas:
1) La señal de red en el estado móvil es inestable, con alto retraso, fácil de sacudir, pérdida de paquetes y canal estrecho;
2) El tipo de acceso a la red móvil y el punto de acceso cambian con frecuencia;
3) Los usuarios móviles utilizan tráfico de alta frecuencia, fragmentado, no WIFI sensible.
(▲ El texto anterior se cita de "Obligatorio para desarrolladores de mensajería instantánea móvil (1): fácil de entender, entiende lo" débil "y" lento "de la red móvil)
Debido a las características mencionadas anteriormente, las aplicaciones móviles enfrentarán varios problemas complejos y cambiables durante la comunicación de datos de la red.
No importa cuán complicada sea esta última tecnología, para que los usuarios comunes usen la APLICACIÓN, es normal que puedan completar las solicitudes de red sin problemas. En otras palabras, la tasa de éxito de la solicitud de red de APP se refleja directamente en su capacidad para determinar directamente la disponibilidad de los servicios de APP, lo que afecta directamente la calidad de los servicios, como la comunicación de datos, la reproducción de video, la visualización de publicidad y el pago conveniente.
En este artículo, la aplicación iOS de Iqiyi se utilizará como ejemplo para compartir la práctica técnica de optimizar la tasa de éxito de las solicitudes de redes móviles.
Este artículo ha sido publicado simultáneamente en mi cuenta pública "Círculo de tecnología de mensajería instantánea".
2. Factores que conducen a la falla de las solicitudes de redes móviles
Para optimizar la tasa de éxito de la solicitud de la red del terminal móvil, primero comprendamos qué enlaces la cadena completa de la solicitud de la red del terminal móvil puede hacer que la solicitud falle.
Estos enlaces a menudo son causados por los siguientes dos tipos de factores:
La primera categoría: factores no mejorables:
1) Control de acceso al sistema iOS de la aplicación, modo de vuelo o sin conexión de red. Detecte e identifique estas tres situaciones y solicite al usuario a través de los métodos apropiados;
2) El enrutador está defectuoso.
La segunda categoría: factores que pueden mejorarse:
1) La fuerza de la señal celular / Wifi y el estado de conexión falsa de congestión de conexión;
2) falla de DNS (como secuestro de DNS, etc.);
3) fallo del nodo local del operador;
4) Falla de equilibrio de carga de operación propia;
5) Falla del servidor empresarial: error de respuesta HTTP, correspondiente a la tasa de error de respuesta HTTP de APM;
6) Errores de lógica de negocios: monitorear los resultados de análisis de subclases, correspondientes al monitoreo de tasa de error de análisis de APM.
Para factores no mejorables: en la actualidad, solo el tipo de falla se puede identificar a través del diagnóstico de red, y el usuario es guiado para autorizar manualmente el acceso a la red o conectarse a una red disponible.
Entre ellos, si el enrutador está defectuoso, puede guiar al usuario a reiniciar el enrutador o cambiar 4G. A través del monitoreo de datos de la aplicación iQIYI, puede ver aproximadamente que la conexión a Internet del usuario representó aproximadamente el 3,8% del tiempo, lo que demuestra que es muy importante proporcionar un buen aviso sin conexión a Internet. La red y 1 señal de red representaron aproximadamente el 9% del tiempo, y también se puede ver la complejidad del entorno de red móvil.
Según los factores que pueden mejorarse, las soluciones se pueden dividir aproximadamente en tres categorías:
1) Errores de la capa de red, correspondientes a los factores 1 a 4. Principalmente reflejado como un error informado a lo largo del tiempo;
2) Error de respuesta HTTP, factor correspondiente 5. El código de estado HTTP es 400 y superior;
3) Error de análisis, correspondiente al factor 6. Supervisado por la interfaz sobrecargada definida por la biblioteca de red de línea de base.
Para mejorar la tasa de éxito de las solicitudes de red, primero debe establecerse un sistema de monitoreo, de modo que la biblioteca de red de línea base pueda entregar datos de solicitud de red de varias dimensiones a APM a través del módulo de estadísticas de red. Con las estadísticas de datos APM, podemos descubrir efectivamente la causa del fallo de la red al final y luego resolver el problema.
Además, debido a la gran cantidad de datos de solicitud de red en el extremo y la limitación del espacio de almacenamiento, APM solo puede muestrear el 2% de los usuarios. Por lo tanto, las solicitudes de red para servicios clave (como la página de inicio) se recopilan por completo para optimizar la tasa de éxito Para lograr una evaluación más objetiva e integral.
3. Proporcionar diferentes ideas de compensación para diferentes negocios a nivel de biblioteca de red de línea de base
Antes de la optimización, se puede concluir el análisis de la clasificación APM: el principal error del fallo de la solicitud es que la proporción de tiempo de espera (-1001) alcanza el 90%. Al mismo tiempo, se siguen de cerca los errores de SSL y los errores de resolución de DNS. Según estas estadísticas, volver a intentarlo se convierte en la medida más importante para optimizar la tasa de éxito de las solicitudes.
Después de una exploración y práctica continuas, la biblioteca de red de línea de base proporciona cuatro métodos de reintento diferentes para diferentes necesidades comerciales.
1) Reintento de conexión directa de IP, controle el número de veces de reintento configurando el número de IP de conexión directa:
El Esquema permanece sin cambios y el Host usa IP directamente (para eliminar el riesgo de resolución de nombres de dominio). Debido a que esta acción requiere que cada línea de servicio proporcione su propia IP conectada directamente, los servicios de acceso actuales son principalmente servicios que requieren conexión HTTPS, como el inicio de sesión.
2) Reintento de super pipeline, puede configurar 1 a 3 reintentos:
La compañía desarrolla el servicio de proxy de puerta de enlace basado en HTTP (similar al proxy remoto de charles). El host se cambia a IP proxy (para eliminar el riesgo de resolución de nombre de dominio), y el esquema se cambia a HTTP (para eliminar el riesgo de SSL, h2 se degrada a HTTP1.1). Dado que esta medida requiere un costo de tráfico, los servicios a los que se accede actualmente son todos los servicios básicos clave, como la página de inicio.
3) Reintento HTTP, puede configurar 1 ~ 3 reintento:
El esquema se modificó a HTTP (para eliminar el riesgo de SSL, h2 se degradó a HTTP1.1), y el resto permaneció sin cambios. Dado que es un método de reintento inclusivo, actualmente está conectado al negocio general del núcleo no crítico.
4) Vuelva a intentar la URL original, puede configurar 1 a 3 intentos de reintento:
El esquema y el host son iguales, vuelva a intentar en el sentido habitual, simplemente solicite nuevamente. Este movimiento actualmente no es un método de reintento recomendado y se deja a discreción de la parte comercial.
Además de un único método de reintento que se puede volver a intentar varias veces, la biblioteca de red básica también admite una combinación de múltiples métodos de reintento. La prioridad de los cuatro métodos de reintento es: reintento directo IP> reintento de super pipeline> reintento HTTP> original Reintento de URL. Después de deducir la situación sin internet, la tasa de éxito de la interfaz CARD en la página de recomendaciones de la página de inicio alcanzó el 99.76% al final del primer trimestre de 2020 a través del reintento combinado.
4. Otros factores que afectan la tasa de éxito de las solicitudes de red de terminal móvil
Además de volver a intentarlo, los siguientes factores tienen un impacto directo en la tasa de éxito de las solicitudes de red.
1) HTTP / 2 vs HTTP / 1.1: la estrategia de solicitud recomendada es ir a H2 para la primera solicitud, e ir a HTTP / 1.1 cuando falla el reintento:
La mayor mejora de HTTP / 2 sobre HTTP / 1.1 es compartir una conexión TCP (consulte "De HTTP / 0.9 a HTTP / 2: Lea la evolución histórica y las ideas de diseño del protocolo HTTP"). Cuando la red es fluida, es HTTP / 2 trae una ventaja en velocidad. Pero cuando la red se daña, el número de secuencia absoluta de los paquetes TCP provocará la pérdida de un paquete y bloqueará todas las solicitudes posteriores. Esta conexión TCP única aumentará la congestión y aumentará la posibilidad de que falle la solicitud.
NSURLSession se adapta al protocolo HTTP y no puede controlar el uso de HTTP / 2 o HTTP / 1.1. Sin embargo, debido al hecho de que el estándar de la industria requiere que HTTP / 2 sea HTTP, esto puede reducirse indirectamente a HTTP / 1.1 cambiando el Esquema de URL a HTTP.
2) La configuración adecuada del tiempo de espera es un factor importante:
El tiempo de espera de NSURLSession es en realidad un tiempo de espera entre paquetes TCP, no un tiempo de espera largo para la solicitud general.
La estrategia de configuración de tiempo de espera recomendada es: el tiempo de espera para la primera solicitud puede ser menor y el tiempo de espera para volver a intentarlo debe ser mayor.
3) Las solicitudes de interfaz que son demasiado densas y concurrentes pueden reducir la tasa de éxito de la solicitud:
Por ejemplo, después de cargar la interfaz de reproducción del registro de reproducción, la tasa de éxito sigue siendo solo del 98,2%. APM monitorea que la tasa de falla de esta interfaz en el entorno IPv4 es solo 0.47%, mientras que la tasa de falla de IPv6 es tan alta como 7.07%. Al optimizar la estrategia de solicitud al final y reducir la densidad de concurrencia de la interfaz, tanto el entorno IPv6 como el entorno IPv4 aumentan a una tasa de éxito del 99.85%.
4) Cuanto más pequeño es el volumen de datos de la interfaz, mayor es la tasa de éxito de la solicitud:
Tanto HTTP / 2 como HTTP / 1.1 se basan en conexiones TCP: cuanto menor es el volumen de datos de la interfaz, menos paquetes TCP deben transmitirse y se reduce la probabilidad de falla de transmisión. En la actualidad, la aplicación iQIYI está cambiando de gzip a br con una tasa de compresión más alta (refiriéndose al algoritmo de compresión Brotl. Para más detalles, consulte: "Habilitar el algoritmo de compresión Brotl y reducir el tráfico CDN en un 20% en comparación con la compresión Gzip").
5. Medidas de optimización para mejorar la robustez y prevenir el mal funcionamiento.
Después de mejorar la tasa de éxito de la red a través de varias medidas de optimización, también hemos evitado con éxito la disminución instantánea en la tasa de éxito causada por fallas en línea a través de las siguientes medidas, lo que ha mejorado la solidez de las solicitudes de red.
1) La robustez de la super tubería en sí:
El siguiente caso muestra que la tasa de error de la interfaz con el reintento de super pipeline es solo del 3,95%, mientras que la tasa de error de la interfaz sin reintento de super pipeline es tan alta como 28,96%. En este momento, no se ha utilizado la IP de recuperación de desastres remota. Después de superponer la IP de recuperación de desastres remota, la curva de tasa de error puede ser casi uniforme.
2) Reintento de HTTP y reintento de URL original En el entorno de doble pila v4v6, se da prioridad a IPv4:
Dado que IPv6 todavía está en construcción, algunas interfaces tienen un rendimiento más débil en IPv6 que IPv4, por lo que puede especificar que intente IPv4 nuevamente.
3) Ahorro TLS1.3– 1RTT:
TLS1.3 reduce los 2 RTT del protocolo de enlace SSL a 1 RTT, lo que reduce la probabilidad de falla del protocolo de enlace SSL. A partir de iOS 12.2, NSURLSession admite TLS1.3. Solo necesita actualizar el servidor para admitir TLS1.3, no es necesario cambiarlo al final.
4) carreras de conexión compuesta IP:
Usando la conexión TCP para medir la velocidad, el propósito es eliminar la IP incorrecta y seleccionar la mejor IP, para aumentar la probabilidad de éxito de la solicitud.
Después de la optimización continua de las medidas anteriores, la aplicación iQiyi ha alcanzado una tasa de éxito comercial del 99.7% a fines de 2020Q1 después de deducir las condiciones sin red, y una tasa de éxito de la capa de red del 99.77%.
▲ Tasa de éxito empresarial = tasa de éxito de la capa de red + tasa de éxito de respuesta HTTP + tasa de éxito de análisis
Una vez completada la optimización, la biblioteca de red básica de la aplicación iQiyi se compone de la siguiente manera:
Como se muestra en la figura anterior, las funciones de cada plantilla de la biblioteca de red básica son las siguientes:
1) Biblioteca de red unificada: proporcione una capa de interfaz de red, todas las interfaces comerciales están conectadas para usar la capa de interfaz de red;
2) Biblioteca de red unificada: proporciona una capa de encapsulación de red, que está conectada a la capa de red del sistema iOS NSURLSession, ASIHTTPRequest (basada en CFNetwork) y la puerta de enlace de conexión larga desarrollada por la empresa;
3) Módulo de estadísticas de red: los valores de tiempo y estado desde el inicio de la llamada comercial hasta la devolución de llamada a la parte comercial se convierten en datos estadísticos y se cargan en la confluencia APM;
4) Módulo de diagnóstico de red: diagnostique negocios críticos, incluyendo análisis de dns, ping, tcpconnect, trace y otras herramientas para analizar IP específica y cargar los resultados del análisis a APM;
5) Módulo de detección de red débil: al referirse a la detección de red débil de Facebook, se basa en la clasificación de velocidad de red de ajuste de velocidad de red, que se divide en condiciones de red muy pobres (red 2G o sin red), condiciones de red pobres (3G), condiciones generales de red, Cinco niveles de buenas condiciones de red y muy buenas condiciones de red;
6) Módulo HTTPDNS: resuelve efectivamente el problema del secuestro del operador;
7) Reintento de súper canalización: proxy de puerta de enlace basado en HTTP con capacidad de proxy de recuperación de desastres remota;
8) módulo ipv4 / ipv6: identifique si es un entorno solo ipv4, doble pila v4 / v6 o un entorno solo ipv6 al final;
9) Módulo de conexión compuesto: se puede seleccionar la mejor IP en el grupo de caché de IP del servidor, que incluye la carrera de conexión de IP de destino, la clasificación de datos estadísticos de solicitud histórica de IP;
10) Módulo de registro de red: registra los datos detallados de la solicitud de red fallida recientemente y los datos de diagnóstico de red. Enviar con los comentarios, puede solucionar fácilmente los problemas de red en línea.
6. Objetivos futuros y posibles medidas de optimización.
Para optimizar continuamente la tasa de éxito de la red, el siguiente objetivo es deducir las condiciones sin red, y la tasa de éxito de las empresas clave alcanza el 99,9%. Las medidas de optimización consideradas posteriormente son las siguientes.
1） Ruta múltiple ：
Cuando el Wifi está falsamente conectado, puede tomar tráfico celular, e iOS 7 admite la función Multipath (consulte: "Presentación del TCP Multipath de iOS 7").
2） QUIC ：
QUIC se basa en UDP. Debido a la pérdida de paquetes dirigida de UDP por parte de los operadores, el QUIC medido no mostró sus ventajas. Sin embargo, teniendo en cuenta que libcurl ya ofrece capacidades QUIC completas en 2019, NSURLSession también admitirá QUIC pronto. A medida que se reduce la interferencia del operador con los paquetes UDP, se reflejarán las ventajas de QUIC.
Si está interesado en el protocolo QUIC, puede leer los siguientes artículos:
3) Simultaneidad de programación inteligente:
Identificación de red débil más precisa y sensible, inclinando el negocio principal clave bajo la red débil.
4) Capacidad de inserción de HTTPDNS:
Después de que HTTPDNS pasó por el sistema de monitoreo de calidad de APM, la IP defectuosa se desconectó a tiempo a través de la inserción.
(Este artículo ha sido publicado simultáneamente: http://www.yongshiyule178.com t / thread-2981-1-1.html)
7. Materiales de referencia.
[1] Resumen de los métodos de optimización de la conexión corta de la red moderna de terminales móviles: velocidad de solicitud, adaptación de red débil, garantía de seguridad
[2] Los desarrolladores de mensajería instantánea de terminal móvil deben leer (1): fácil de entender, comprender lo "débil" y "lento" de la red móvil
[3] Debe leer para desarrolladores de mensajería instantánea móvil (2): Resumen de los métodos de optimización de redes débiles móviles más completos de la historia
[4] Comprenda completamente las diversas enfermedades como el secuestro de nombres de dominio DNS en el terminal móvil: principios técnicos, fuente de problemas, soluciones, etc.
[5] La práctica de optimización de DNS móvil de la aplicación Meitu: el tiempo de solicitud HTTPS se reduce a casi la mitad
[6] Intercambio de prácticas de optimización en profundidad de la red de terminales móviles de la aplicación Baidu (1): optimización de DNS
[7] Baidu APP terminal móvil red de intercambio de prácticas de optimización en profundidad (2): optimización de conexión de red
[8] Uso compartido de la práctica de optimización profunda de la red de terminales móviles de la aplicación Baidu (3): optimización de redes móviles débiles