Práctica de optimización de redes móviles

La optimización de la red es crucial para la experiencia del usuario de los productos de la aplicación y está estrechamente relacionada con las operaciones y los ingresos de la empresa. Aquí hay dos datos públicos:

"Si la página se carga durante más de 3 segundos, el 57% de los usuarios la abandonarán."

"La extensión de carga de la página de Amazon de 1 segundo disminuirá en al año 1.600 millones de dólares en ingresos”.

El primero es el problema de la indisponibilidad de la red. Principalmente causado por las siguientes razones:

Interceptación de GFW, ya sabes el motivo.

Secuestro de DNS, bloqueo accidental de puertos, etc.

La infraestructura de red en áreas remotas es relativamente pobre.

En segundo lugar, el tiempo de carga de la red es largo. Las razones incluyen: * Para ahorrar energía, los dispositivos móviles necesitan precalentar el chip de comunicación antes de emitir solicitudes de red. * Las solicitudes de red deben cruzar operadores de red y tener rutas físicas largas. * Las solicitudes HTTP están diseñadas en función de Sockets. Se someterán a tres apretones de manos antes de que se inicie la solicitud y a cuatro apretones de manos más cuando se desconecten.

Por último, está el problema de la seguridad de los datos del protocolo HTTP. Las razones son: * Los datos del protocolo HTTP se capturan fácilmente. Los datos del cuerpo posterior al paquete se cifran para evitar fugas, pero la URL y las partes del encabezado en el protocolo seguirán expuestas al software de captura de paquetes. HTTPS enfrenta problemas similares. * Los datos del operador han sido alterados de forma grave y maliciosa. Como se muestra en la imagen siguiente, el operador ha insertado anuncios en la página web de la aplicación.

3

Ante los problemas de red anteriores, primero hicimos algunos intentos de optimización en las solicitudes de conexión corta HTTP.

1. Di adiós a los DNS y usa la dirección IP directamente

Si es la primera vez que envías un servicio de red basado en el protocolo HTTP, lo primero es realizar el nombre de dominio DNS resolución Hemos contado Resolución de DNS La tasa de éxito es solo del 98%, y el 2% restante se debe a una falla de resolución o al secuestro de DNS del operador (el DNS local devuelve una dirección IP que no es de origen. Al mismo tiempo, la resolución de DNS tarda aproximadamente). 200 milisegundos en 3G y unos 100 milisegundos en 4G, con retrasos evidentes. Según la conexión TCP, omitimos directamente la etapa de resolución de DNS y utilizamos la lista de IP incorporada para la conexión de red.

La aplicación tiene una lista incorporada de IP de servidor y cada IP tiene un peso. Cada vez que se establezca una nueva conexión, se seleccionará la dirección IP con mayor peso para la conexión. Cuando se inicia la aplicación, todos los pesos de la lista de IP son iguales. En este momento, se iniciará un conjunto de operaciones de ping. El peso de la IP se calcula en función del tiempo de retraso del valor de ping. La razón es que cuanto menor sea el valor de ping de la dirección IP, mejor será la dirección IP después de la conexión. El retraso en la transmisión de la red también debería ser relativamente menor. La industria también utiliza HTTP DNS para resolver el problema del secuestro de DNS y devolver la IP del servidor más adecuada para la red del usuario. Sin embargo, el desarrollo y la implementación de HTTP DNS requiere costos de desarrollo considerables y actualmente no lo utilizamos.

La lista de IP del servidor incorporada también se actualizará cada vez que se inicie la aplicación, habrá un servicio de configuración móvil (que admite servicios de tipo de red TCP y HTTP) para actualizar la lista de IP del servidor. Servidores de soporte de diferentes líneas de productos. Lista de IP actualizada. Por lo tanto, la función de la resolución DNS tradicional para resolver el desvío multi-IDC también se puede resolver mediante este método.

2. Optimización de la conexión de socket, reduciendo el tiempo de conexión

Al igual que la función Keepalive en el protocolo HTTP, el método de optimización más directo para reducir el tiempo de servicio de la red es mantener conexiones largas. Cada conexión de protocolo de enlace de tres vías TCP requiere un RTT (tiempo de ida y vuelta) del cliente y el servidor para completarse, lo que significa un retraso de 100 a 300 milisegundos. El propio mecanismo de "inicio lento" del protocolo TCP para lidiar con la congestión de la red también lo hará; Afecta el rendimiento de transmisión de nuevas conexiones.

La aplicación utiliza un grupo de conexiones largas para utilizar conexiones largas. El grupo de conexiones largas mantiene múltiples conexiones TCP con el servidor. Cada vez que se inicia el servicio de red, se obtendrá una conexión inactiva del grupo de conexiones largas. Conexión larga: después de completar el servicio de red, la conexión TCP se devuelve al grupo de conexiones largas. No implementamos mecanismos de canalización y multiplexación en una única conexión TCP, pero adoptamos el mecanismo FIFO más simple por dos razones:

Para simplificar la lógica de procesamiento del servicio de Mobile Gateway y reducir los costos de desarrollo

<; p> Cuando el servidor devuelve varias respuestas al mismo tiempo, si un mensaje de respuesta es muy grande, el uso de varias conexiones largas puede acelerar la recepción de los mensajes de respuesta del servicio.

Si las conexiones TCP en el grupo de conexiones largas están ocupadas cuando se inicia el servicio de red, o el servicio de red de la conexión larga TCP falla, se iniciará una conexión corta TCP para implementar el servicio de red. La diferencia entre conexión larga y conexión corta aquí es solo si se debe cerrar la conexión TCP directamente después de que se complete el servicio.

Adjunto: Existe una diferencia entre Pipeline y Multiplexación. Por ejemplo, HTTP/1.1 admite Pipeline. ¿Puede el cliente enviar varias solicitudes al mismo tiempo? Sin embargo, cuando el servidor devuelve una respuesta, también debe hacerlo. devolver la respuesta en el orden en que se envían las solicitudes; los protocolos SPDY y HTTP/2 admiten multiplexación, es decir, admiten la devolución desordenada de mensajes de respuesta. El envío de solicitudes y la recepción de respuestas no interfieren entre sí. , evitando así el problema de bloqueo del encabezado de línea que no puede resolverse por completo mediante HTTP/1.1 Pipeline.

3. Red débil y optimización de la fluctuación de la red

La aplicación introduce parámetros de calidad de la red, que se calculan en función del tipo de red y el valor de ping de un extremo a otro, y cambia las estrategias de servicio de la red. según la diferente calidad de la red:

Ajuste el número de grupos de conexiones persistentes: por ejemplo, en la red Egde 2G/2,5G, el número de grupos de conexiones persistentes se reducirá a 1 (el operador limitará el número de conexiones TCP para una única IP de destino); puede aumentar el número de grupos de conexiones largas y otros mecanismos.

Ajusta dinámicamente el tiempo de espera de la conexión TCP, escritura y lectura.

Al cambiar de tipo de red, como WIFI y redes móviles, o al cambiar de 4G/3G a 2G, la dirección IP del cliente cambiará y el socket TCP conectado está destinado a no ser válido (cada socket corresponde a una tupla de cuatro dimensiones: IP de origen, puerto de origen, IP de destino, puerto de destino. En este momento, todas las conexiones largas inactivas se cerrarán automáticamente y los servicios de red existentes también volverán a intentarlo automáticamente según el estado.

4. Optimización del formato de datos, reduciendo el volumen de transmisión de datos y el tiempo de serialización

Cuanto menor sea la cantidad de datos transmitidos, más corto será el tiempo de transmisión en la misma conexión TCP. La aplicación Ctrip solía utilizar un conjunto de formatos de datos diseñados por ella misma. Más tarde, después de compararla con Google ProtocolBuffer, se descubrió que el tamaño del paquete de datos para tipos de datos específicos se reducirá entre un 20 y un 30%, y el tiempo de serialización y deserialización puede reducirse. se reducirá entre un 10% y un 20%. Por lo tanto, actualmente los servicios Core están migrando gradualmente al formato ProtocolBuffer. Además, Facebook compartió una vez su práctica de utilizar el formato de datos FlatBuffer para mejorar el rendimiento. Después de nuestro análisis, no era adecuado para los escenarios comerciales de Ctrip y, por lo tanto, no se utilizó.

5. Introducir un mecanismo de reintento para mejorar la tasa de éxito del servicio de red

Inspirándonos en el mecanismo de retransmisión del protocolo TCP para garantizar una transmisión confiable, también introdujimos un mecanismo de reintento a nivel de aplicación para mejorar la tasa de éxito de los servicios de red.

Descubrimos que más del 90% de las fallas del servicio de red se deben a fallas en la conexión de la red. En este momento, encontramos que existe la posibilidad de que la conexión se realice correctamente y el servicio se complete. que el ciclo de vida del servicio de red mencionado anteriormente es 1: establecimiento de conexión, serialización. Cuando fallan las tres etapas del mensaje de solicitud de red y el envío de la solicitud de red, se pueden volver a intentar automáticamente, porque podemos estar seguros de que la solicitud aún no ha llegado al servidor. para el procesamiento, y no habrá ningún problema de idempotencia (si hay un problema de idempotencia, pueden ocurrir pedidos duplicados). Cuando el servicio de red necesite volver a intentarlo, utilizará conexiones cortas para compensar en lugar de conexiones largas.

Después de implementar el mecanismo anterior, la tasa de éxito del servicio de red de la aplicación Ctrip ha aumentado del 95,3%+ original al 99,5%+ actual (la tasa de éxito del servicio aquí se refiere a la tasa de éxito del servicio de extremo a extremo). , es decir, el cliente El número de éxito del servicio recopilado se calcula dividiendo el número total de solicitudes y no distingue entre las condiciones actuales de la red), y el efecto es significativo.

6. Otros mecanismos y trucos de servicios de red

La aplicación Ctrip también implementa algunos otros mecanismos de servicios de red para facilitar el desarrollo empresarial, como el mecanismo de prioridad de servicios de red, los servicios de alta prioridad se utilizan primero y Conexión a largo plazo, los servicios de baja prioridad utilizan conexiones cortas de forma predeterminada; el mecanismo de dependencia del servicio de red inicia o cancela automáticamente los servicios de red en función de las dependencias. Por ejemplo, cuando el servicio principal falla, el subservicio se cancela automáticamente.

Durante el proceso de desarrollo, también encontramos algunos trucos de desarrollo de TCP Socket en plataformas móviles:

La interfaz nativa de Socket en la plataforma iOS crea una conexión y no activa la red móvil. Aquí está la interfaz de socket nativa. Se refiere a la interfaz de socket POSIX. La red debe activarse solo cuando se utiliza CFSocket o la interfaz de red de capa superior para intentar una conexión de red. Por lo tanto, cuando se inicia la aplicación Ctrip, dará prioridad a activar y registrar algunos SDK de terceros y enviar solicitudes HTTP para activar la red móvil.

Configure varios parámetros de Socket de manera adecuada: el parámetro SO_KEEPALIVE garantiza que se mantenga la conexión TCP (nota: este KeepAlive es un atributo en TCP, y KeepAlive de HTTP son dos conceptos de escenario), el parámetro SO_NOSIGPIPE cierra el evento SIGPIPE y TCP_NODELAY El parámetro desactiva el impacto del algoritmo TCP Nagle.

Dado que iOS requiere compatibilidad con redes IPv6 únicamente, el uso de Socket nativo debe admitir IPv6.

Si utiliza select para manejar operaciones de E/S sin bloqueo, asegúrese de que los diferentes valores de retorno y parámetros de tiempo de espera se manejen correctamente.

Mecanismo de latido para mantener la disponibilidad de conexiones largas TCP: para aplicaciones que no son de mensajería instantánea, el mecanismo de latido es de poca utilidad porque los usuarios activarán constantemente solicitudes para usar conexiones TCP, especialmente en escenarios comerciales de Ctrip, a través de datos. Las estadísticas muestran que el uso o no del latido tiene un impacto mínimo en el tiempo de servicio y la tasa de éxito, por lo que el mecanismo de latido se ha desactivado por ahora. El mecanismo de latido original es que la conexión TCP inactiva en el grupo de conexiones largas TCP envía un paquete de latido a la puerta de enlace cada 60 segundos, y la puerta de enlace devuelve un paquete de respuesta de latido, lo que permite a ambas partes confirmar que la conexión TCP es válida.

Optimización del servicio de red híbrida

Una proporción considerable del negocio en la aplicación Ctrip se implementa utilizando tecnología híbrida y se ejecuta en el entorno WebView, donde se encuentran todos los servicios de red (solicitudes HTTP). controlado por el sistema y no podemos controlarlo, por lo que no podemos optimizarlo. Su tasa de éxito del servicio de un extremo a otro es solo alrededor del 97% (nota: esto se refiere a la solicitud de servicio de red enviada por la lógica empresarial en la página, no). la solicitud de recurso estático).

Hemos adoptado una solución técnica llamada "Túnel TCP para híbridos" para optimizar los servicios de red híbrida. A diferencia del método de los productos de aceleración HTTP tradicionales, no interceptamos las solicitudes HTTP y luego las reenviamos. La capa en el marco Ctrip Hybrid cambia automáticamente.

Como se muestra en la figura, el proceso de esta solución técnica es el siguiente:

Si la aplicación admite el túnel TCP para híbrido, cuando la empresa híbrida envíe servicios de red, será reenviado a la aplicación nativa a través de la interfaz híbrida. Este módulo encapsulará esta solicitud HTTP y la reenviará a la puerta de enlace TCP como carga útil del servicio de red TCP.

La puerta de enlace TCP determinará que es un servicio de reenvío híbrido; según el número de servicio y descomprímalo, la carga útil se reenvía directamente a HTTP Gateway. Esta solicitud HTTP es transparente para HTTP Gateway. No es necesario distinguir si se trata de una solicitud HTTP enviada directamente desde la aplicación o reenviada por TCP Gateway.

Una vez completado el procesamiento del servicio empresarial back-end, la respuesta HTTP se devolverá a TCP Gateway a través de HTTP Gateway, y TCP Gateway devolverá esta respuesta HTTP como carga útil a la capa de comunicación de red TCP de la aplicación. ;

La capa de comunicación de red TCP deserializará la carga útil y la devolverá al marco híbrido y, finalmente, devolverá la llamada asíncrona a la persona que llama a la empresa híbrida. Todo el proceso también es transparente para quien llama al servicio híbrido, que no conoce la existencia del túnel TCP.

Después de adoptar esta solución técnica, la tasa de éxito del servicio de red del negocio híbrido en la aplicación Ctrip ha aumentado a más del 99% y el consumo de tiempo promedio se ha reducido en un 30%.

Optimización del servicio de red en el extranjero

Actualmente, Ctrip no implementa IDC en el extranjero. Los usuarios en el extranjero necesitan acceder a los IDC nacionales cuando utilizan la aplicación, y el tiempo promedio de servicio es significativamente mayor que el de los nacionales. usuarios. Adoptamos una solución técnica llamada "TCP Bypass for Oversea" para optimizar el rendimiento de los servicios de red en el extranjero. Utilizamos principalmente los canales de red exclusivos de Akamai en el extranjero. Al mismo tiempo, implementamos equipos de oficina central en el IDC nacional de Ctrip y utilizamos canales de aceleración dedicados. Mejorar la experiencia del usuario en el extranjero.

Después de iniciar la aplicación, los usuarios extranjeros primero obtienen la IP del servidor a través del nombre de dominio personalizado de Akamai, y todos los servicios de red utilizarán primero el canal de Akamai si el servicio de red del canal de Akamai falla y el mecanismo de reintento; entra en vigor, se utilizará el canal tradicional de Internet. Inténtelo de nuevo. En comparación con el uso exclusivo de canales de Internet tradicionales, aunque se mantiene sin cambios la tasa de éxito de los servicios de red, el tiempo promedio de servicio se reduce en un 33 % después de utilizar la tecnología de derivación de canales de Akamai.

Discusión sobre otros protocolos de red

En los últimos dos años, nuestro trabajo de optimización de servicios de red se ha basado en el protocolo TCP y básicamente hemos logrado los objetivos de optimización. Sin embargo, en los últimos dos años, los nuevos protocolos de red de capa de aplicación SPDY y HTTP/2 se han ido incorporando gradualmente a la corriente principal. El protocolo QUIC basado en UDP también parece muy interesante y merece una investigación de seguimiento.

SPDY y HTTP/2

SPDY es un protocolo de capa de aplicación de red desarrollado por Google basado en TCP. Detuvo su desarrollo y cambió para admitir el protocolo HTTP/2 basado en SPDY. diseño de logros. HTTP/ 2 La mejora principal del protocolo es en realidad optimizar los puntos débiles que afectan el rendimiento de latencia en HTTP/1.x:

Compresión de encabezados: comprime los encabezados de solicitud y respuesta HTTP redundantes.

Soporte de multiplexación: admite múltiples solicitudes y respuestas en una conexión TCP al mismo tiempo.

Mantiene vivas las conexiones (más minucioso que HTTP/1.x): Reduce los tiempos de conexión de red.

Soporte push: el servidor puede enviar datos activamente al cliente.

Los resultados oficiales de las pruebas de rendimiento muestran que el tiempo de carga de la página usando SPDY o HTTP/2 se reduce en aproximadamente un 30%. Sin embargo, estos son resultados de pruebas para páginas web para servicios de red en la aplicación. Todavía estamos en el proceso de optimizar los resultados específicos de las pruebas internas, pero el método de optimización parece ser similar al método de optimización que utilizamos actualmente en el protocolo TCP, por lo que el efecto de optimización del rendimiento puede no ser muy significativo.

QUIC

QUIC es un protocolo de capa de aplicación desarrollado por Google basado en UDP. El protocolo UDP no requiere conexión y no tiene un mecanismo de retransmisión, por lo que la capa de aplicación debe hacerlo. garantizar la confiabilidad del servicio. En la actualidad, Tencent en China ha probado el protocolo QUIC para redes débiles y también lo estamos probando. Si finalmente se adoptará depende de los resultados de la prueba.

Resumen

La tecnología es sólo un medio, y en última instancia debe reflejarse en los resultados empresariales. Hemos implementado que, a excepción de los recursos estáticos y otras solicitudes de red que necesitan acceder a CDN, otros servicios de red de aplicaciones utilizan un canal TCP unificado, por lo que tienen mejores capacidades de ajuste del rendimiento y monitoreo empresarial. La optimización actual de Ctrip de varios servicios de red de aplicaciones basados ​​​​en el protocolo TCP también es un equilibrio de varias soluciones técnicas. Aunque nuevos protocolos como HTTP/2 están madurando gradualmente, la flexibilidad del protocolo TCP en sí admite la optimización del rendimiento específica, y todavía lo es. sus ventajas Con ventajas especiales, esperamos que nuestro resumen práctico pueda ser de algún valor de referencia para los profesionales de la tecnología inalámbrica nacional.