Estrategias de manejo para conexiones de red de terminales móviles en redes débiles
Cómo medir y simular "redes débiles" es de gran importancia para el desarrollo de aplicaciones móviles, como ahorrar costos de prueba, problemas fácilmente recurrentes y acelerar la velocidad de lanzamiento de productos.
El método general consiste en utilizar "tasa de pérdida de paquetes" y "retraso de red" para definir y medir la "red débil".
2. El proceso de acceso del teléfono móvil al servidor.
Para hablar de este problema, primero debemos comprender el proceso de acceso del teléfono móvil al servidor.
En primer lugar, el teléfono móvil puede comunicarse con la red sólo si obtiene una asignación de enlace inalámbrico desde la estación base a través del protocolo de red inalámbrica.
Por otro lado, la estación base de la red inalámbrica y el controlador de la estación base distribuyen señales a los teléfonos móviles, y se ha completado la conexión e interacción de los teléfonos móviles.
Después de obtener el enlace inalámbrico, la red se conectará, cifrará y autenticará. La red central verificará si puede conectarse a la red, si tiene un paquete, si está en roaming, etc. La red central es SGSN y GGSN, y en este paso se completa la conversión de protocolo entre el protocolo de red inalámbrica y Ethernet por cable.
A continuación, la red central le proporcionará la selección de APN, la asignación de IP y la facturación inicial.
Más abajo, están los pasos de la red tradicional: respuesta de consulta DNS, establecimiento de enlace TCP, HTTP GET, respuesta RTTP 200 OK, datos de respuesta HTTP, datos de la última respuesta HTTP y visualización de la interfaz de usuario.
Este es todo el proceso por el que un teléfono móvil accede al servidor a través de una red inalámbrica. Hay varias preguntas que molestan a los desarrolladores durante todo el proceso:
¿Cómo asigna la red inalámbrica los enlaces inalámbricos a los teléfonos móviles?
La red central dispone de un Punto de Acceso (APN). ¿Cuál es la diferencia entre CMNET y CMWAP aquí, solo protocolo? ¿Cuál es la diferencia entre el reenvío de datos? ¿Existe alguna diferencia en la transmisión de un paquete de datos en diferentes redes?
¿Cómo pueden los usuarios encontrar un servidor adecuado lo más rápido posible? ¿Cómo cargar contenido de forma rápida y eficaz y mostrarlo en primer lugar?
El foco de estos problemas reside en varios puntos de conexión:
3.2 Regla del segundo
Basado en la situación anterior, una característica importante de las redes inalámbricas es formado: 2. Nivel de gestión estatal y nivel 2 de transferencia de estado. Ambas operaciones tardan entre unos cientos de milisegundos y unos pocos segundos, lo que es demasiado corto para mantener una conexión y demasiado largo para pasar de una conexión sin conexión a otra.
Por el contrario, la gestión del estado de las redes cableadas, como la asignación de IP y la liberación de la conexión TCP, se realiza en el nivel de minutos, mientras que la transferencia de estado se realiza en el nivel de milisegundos.
Estos mecanismos de comunicación, sumado a la alta latencia y alta pérdida de paquetes de las redes inalámbricas. Cómo garantizar una calidad de servicio estable y predecible de los productos de Internet móvil se ha convertido en un gran desafío;
El retraso en la transmisión de datos inalámbrica en la red 2G es de varios cientos de milisegundos, mientras que el retraso en la red 4G se reduce a decenas de ms, la transición de estado y la conversión de protocolo de la red central es de 30 ~ 100 ms. El retraso en la red troncal IP está relacionado con la distancia física y la calidad de la interconexión del operador. Es de 50 a 400 ms entre los operadores y 5 para el. mismo operador -80ms, dependiendo de la congestión de la red.
La tasa de error de bits de las redes inalámbricas es dos órdenes de magnitud mayor que la de las redes cableadas, y las fluctuaciones en diferentes períodos de tiempo también son muy grandes.
¿Cómo optimizar los servicios según las características de las redes móviles?
Este es nuestro resumen de la regla del segundo: las acciones prescritas deben completarse en un segundo.
1. Red 2g: complete la consulta dns y establezca una conexión con el servidor backend en 1 segundo.
2. Red 3G: la primera palabra se muestra en 1 segundo (tiempo de la primera palabra)
3. Red WiFi: la primera visualización en pantalla se completa en 1 segundo (tiempo de la primera pantalla) ).
4. Estos indicadores deben medirse en el terminal y deben estar relacionados con la experiencia del usuario: el tiempo de la primera palabra y el tiempo de la primera pantalla deben ser sentidos intuitivamente por el usuario.
Cuarto, ideas de optimización
4.1 Principios de garantía del servicio
Del análisis anterior, se puede ver que garantizar una calidad de servicio estable y predecible de los productos de Internet móvil es a Un gran desafío. Los siguientes principios pueden resultar útiles:
1) Optimización del diseño de la interfaz La optimización de la interfaz no es teóricamente una optimización de la red débil de la aplicación, pero este problema de rendimiento de la API queda realmente expuesto cuando las condiciones de la red no son buenas. . Todo el mundo habla de la calidad del servidor y del rendimiento del equipo.
De hecho, para un buen servidor, la mayoría de los lugares que retrasan la velocidad de la solicitud son IO. Incluyendo IO de lectura y escritura de disco, IO de consulta SQL, etc. Puntos de optimización comunes: monitoreo de consultas lento, optimización de múltiples consultas, almacenamiento en caché de interfaz general, etc.
2) Estrategias relacionadas con la imagen.
1) Usar formatos de imagen más rápidos no es estrictamente una optimización en redes débiles, ¡pero los formatos de imagen más rápidos son realmente importantes! Aquí se recomienda el formato WebP. (Formato WebP, un formato de imagen desarrollado por Google para acelerar la carga de imágenes. El volumen de compresión de imágenes es solo aproximadamente 2/3 del JPEG, lo que puede ahorrar una gran cantidad de recursos de ancho de banda del servidor y espacio de datos. Sin embargo, WebP tiene una compresión con pérdidas. En comparación con codificación de archivos JPEG En comparación con la codificación de archivos WebP de la misma calidad, se requieren más recursos informáticos)
2) Se distribuyen diferentes imágenes en diferentes redes. Por ejemplo (para la imagen original es 600X480): 2/3G usa imágenes de baja definición ->; distribuye imágenes de 300X240 con una precisión de 80 y imágenes 4G con una definición normal -> envía imágenes de 600X480 con una precisión de 80 y wifi; Imágenes de alta definición (mejor a juzgar por la velocidad de la red, WiFi también es lenta) -> Envíe imágenes de 600X480 con una precisión de 100.
3) Desconectar y volver a conectar. Esta es probablemente la característica más importante porque hay muchas razones por las que las conexiones de datos pueden caer en las redes inalámbricas. CDN se puede utilizar aquí. (CDN es una red de distribución de contenido distribuido construida sobre una red de datos. La función de CDN es utilizar la tecnología de clúster de servidores de medios de transmisión para superar las deficiencias del ancho de banda de salida insuficiente y la concurrencia de un sistema de una sola máquina. Puede aumentar considerablemente la cantidad de flujos concurrentes admitidos por el sistema y reducir o evitar los efectos adversos de puntos únicos de falla)
4) Debido a que crear una conexión es una operación muy costosa, la cantidad de creaciones de conexiones de datos debe reducirse tanto como sea posible. posible y agrupar en una sola solicitud tantas tareas como sea posible. Si se envían paquetes de datos pequeños varias veces, intente asegurarse de que se envíen en 2 segundos. Al acceder a diferentes servidores en un corto período de tiempo, multiplexe las conexiones inalámbricas tanto como sea posible.
5), optimizar la consulta DNS. Se deben minimizar las consultas de DNS, se debe evitar el secuestro de nombres de dominio y la contaminación de DNS, y se debe programar a los usuarios en el "mejor punto de acceso".
6) Reducir el tamaño del grupo y optimizar la capacidad del grupo. El tamaño y la capacidad de los paquetes se reducen comprimiendo, adelgazando los encabezados de los paquetes y fusionando mensajes.
7) Controle el tamaño del paquete de datos para que no supere los 1500 para evitar la fragmentación. Incluyendo segmentación de control de enlace lógico, segmentación GGSN y segmentación IP. Entre ellos, cuando el tamaño del paquete de datos excede el valor máximo permitido por GGSN, GGSN puede procesarlo de las siguientes tres formas: cortar, descartar y rechazar.
8) Optimice los parámetros del socket TCP, incluido si se debe desactivar el reciclaje rápido, r inicial, ventana de congestión inicial, tamaño del búfer del socket, Delay-ACK, Selective-ACK, TCP_CORK, algoritmo de congestión (Westwood/TLP). /Cubo) etc. La importancia de esto es que la QoS de las redes de acceso como 2G/3G/4G/WIFI/intranet es muy diferente, por lo que para obtener una mejor calidad de servicio en diferentes redes, los valores de los parámetros anteriores pueden ser muy diferentes. .
9) Optimizar el paquete ACK. Cuando la red es débil, los paquetes ACK en el protocolo TCP son muy caros y el retraso puede incluso alcanzar el segundo nivel. Las características del protocolo TCP, como el control de congestión, la retransmisión rápida y la recuperación rápida, dependen en gran medida del paquete ACK que envía el receptor. Es posible que si el retraso del paquete ACK recibido por el remitente es demasiado largo, afecte seriamente la eficiencia del protocolo TCP. Sin embargo, si se envían demasiados acuses de recibo, se ocuparán demasiados recursos inalámbricos valiosos. En las comunicaciones de redes móviles, "cómo reducir los paquetes de confirmación y al mismo tiempo reducir el retraso de los paquetes de datos en conexiones confiables" es un tema de investigación popular. Idea básica: equilibrar la cantidad de paquetes redundantes y paquetes ACK para reducir el retraso y mejorar el rendimiento. Por ejemplo, la comunicación entre SGSN y GGSN se implementa de la siguiente manera: se comunican a través del protocolo UDP. Cuando no hay ningún paquete de datos nuevo, el remitente reintenta el paquete de datos enviado de vez en cuando, alcanzando el número máximo de reintentos. desechar el paquete.
10), el algoritmo de control de congestión de TCP está diseñado bajo el supuesto de que “la pérdida de paquetes significa congestión de la red”, lo cual es obviamente inapropiado en un entorno de red inalámbrica.
Pero en un entorno de red inalámbrica, al diseñar un protocolo UDP confiable, ¿se puede abandonar por completo el control de la congestión? Hay varios algoritmos de control de congestión compatibles con TCP en entornos de redes inalámbricas en otros artículos. Si está interesado, puede consultarlos usted mismo.
11), utilice de manera flexible conexiones largas/cortas y admita diferentes protocolos (TCP/UDP, http, protocolos binarios, etc.). ), admite diferentes puertos, etc.
12), haciendo que los usuarios se sientan rápidos. De momento ya no se trata de un medio técnico, sino de un juego psicológico, una forma de mejorar la experiencia del usuario. Por ejemplo:
1), una barra de progreso distinta de cero. No importa cómo se carga la página web, no importa cuáles sean las condiciones de la red, el progreso de carga siempre comienza en el 50% y permanece alrededor del 98%.
2) Primero muestra el texto y carga la imagen. Además, en Webview, la velocidad de carga de imágenes o multimedia es definitivamente mucho más lenta que la del texto. Debido a que diferentes WebViews tienen diferentes efectos de visualización y representación, podemos dejar que WebView muestre primero texto y luego imágenes. Ofrezca a los usuarios la sensación de que primero pueden obtener una vista previa de toda la página web.
4.2 Optimización de la programación de acceso
La primera consideración para la optimización de la programación de acceso es reducir el impacto del DNS. El DNS de la red móvil tiene las siguientes características:
1) La red troncal no puede identificar en qué ciudad se encuentra el usuario móvil y el despacho en todos los lugares del este, oeste, norte y sur es no llamado completamente. Actualmente, parte del DNS nacional transporta a más del 40% de los usuarios de toda la red.
2) Muchos teléfonos móviles imitadores tienen configuraciones DNS locales incorrectas.
3) Además, las redes cableadas también encontrarán algunos problemas, como abuso de la resolución DNS del terminal, secuestro de nombres de dominio, contaminación del DNS, envejecimiento, vulnerabilidad, etc. Pero para estos problemas, la autocuración en el escritorio será mejor, pero es más difícil de resolver en el teléfono móvil.
Existen dos métodos principales para solucionar problemas de DNS:
1) Reducir las solicitudes, consultas y actualizaciones de DNS, es decir, realizar almacenamiento en caché de DNS.
2) Configurar la lista de servidores en el terminal y acceder directamente a la IP sin DNS.
Pero esto no es suficiente, porque los usuarios pueden provenir de diferentes operadores nacionales y extranjeros, y la estrategia de programación debe optimizarse aún más:
1), es necesario establecer la caché de DNS más puntos de acceso y utilizar diferentes nombres de dominio para distinguirlos.
2) La lista de IP debe actualizarse para adaptarse a las diferentes condiciones de la red e implementar una programación activa. Por ejemplo, al principio solo atendíamos a los usuarios de dispositivos móviles, y primero garantizamos la calidad del acceso para los usuarios de dispositivos móviles, porque la gran mayoría de los usuarios se concentran en dispositivos móviles, actualmente hay tres operadores nacionales y la proporción de usuarios se está acercando gradualmente, por lo que; necesitamos distinguirlos claramente; los teléfonos inteligentes usan wifi, lo cual no sé si cada operador tiene acceso a China Telecom, China Unicom o no, por lo que no se puede configurar el escenario de antemano y, si es así, se debe establecer el escenario. para resolverlo a través de capacidades de programación en segundo plano.
Una mayor optimización producirá un método de integración:
1) Primero resuelva el nombre de dominio y el cliente podrá conectarse directamente a la IP resuelta, ya sea usando el protocolo http o usando el socket tcp.
2) Combinación de múltiples puertos y múltiples protocolos: diferentes protocolos tienen diferentes restricciones, algunos solo pueden ser http, otros solo pueden ser sockets tcp, todos los entornos deben adaptarse y el cliente no puede admitir solo un protocolo.
3) Medición de velocidad del terminal: Cada vez hay más puntos de acceso. ¿Cuál es adecuado para el acceso? Para elegir, podrás elegir el más rápido a través del test de velocidad del terminal. Por supuesto, puede medir la velocidad cada vez que establece una nueva conexión, pero establecer una conexión puede llevar mucho tiempo. Podemos realizar una programación dinámica en segundo plano en función de los resultados de la medición de velocidad a largo plazo y la medición de velocidad actual; después de establecer una conexión para el usuario. En otras palabras, la primera conexión puede no ser óptima; la velocidad se mide dinámicamente después de que se establece la conexión y luego se transmite al punto de acceso más rápido. El siguiente paso es establecer esquemas de red e ideas de aprendizaje terminal.
En cuanto a la granularidad del muestreo de medición de velocidad, es inútil utilizar segmentos IP para Internet móvil. La mejor granularidad está a nivel de elemento de red. Por ejemplo, hay más de 20 puertas de enlace WAP en Guangdong. La situación de cada puerta de enlace es diferente, por lo que es una granularidad más adecuada.
Finalmente, permítanme enfatizar un principio de toda programación de acceso: la lógica de programación no debe escribirse en el cliente, debe completarse en segundo plano.
4.3 Optimización del protocolo
Se enumera brevemente la optimización de los parámetros del protocolo, que es una experiencia resumida en el proceso de operación a largo plazo.
Al iniciar los servicios de Internet móvil, como especificación operativa, se pueden evitar muchos desvíos:
1. Desactivar la recuperación rápida de TCP.
2. El RTO inicial no es inferior a 3 segundos.
3. La ventana inicial de control de congestión no es inferior a 10. Debido a que la mayoría de las páginas tienen menos de 10 kB, muchas solicitudes finalizan durante la fase de inicio lento. Cambiarlo a 10 puede reducir el retraso en la transmisión de recursos de páginas pequeñas. Cuanto mayor sea el contenido, menos efectiva será esta opción.
4. Búfer de socket y gt64k
5. La ventana deslizante de TCP es variable
6. Controle el tamaño del paquete a 1400 bytes a continuación para evitar la fragmentación.
Los principios de optimización del protocolo se resumen a continuación:
1. Reutilización de la conexión
2. Control de conexión concurrente
3. control
p>4. Encabezados optimizados
5. Compresión de contenido
6. Ya sea TCP, HTTP, UDP, conexiones largas, GZIP, SPDY, WUP o WebP, cada protocolo y solución tiene sus propias razones y no hay ningún problema de optimización. Es necesario verificar y seleccionar durante el proceso de operación si es adecuado para las características de sus productos y servicios.
4.4 Optimización del punto de acceso WAP
Con respecto a la optimización del punto de acceso WAP, algunas personas pueden decir que nuestra aplicación es una aplicación elegante y de alta gama y que no necesita optimización WAP. De hecho, nuestras estadísticas muestran que actualmente entre el 5% y el 20% de los usuarios eligen * *WAP (CMWAP, 3GWAP, CTWAP), que incluye incluso algunos terminales iPhone. De hecho, la puerta de enlace WAP es esencialmente un proxy y no está completamente al revés. También evoluciona con el avance de la tecnología. En el futuro, es posible que haya puertas de enlace integradas y puertas de enlace de contabilidad de contenido para reemplazar las puertas de enlace WAP actuales en la arquitectura de red. Se recomienda considerarlas juntas. Las siguientes son algunas cuestiones a las que se debe prestar atención al optimizar WAP:
1. Página de recordatorio de tarifas
Procesamiento de salto 2302
3. -host Uso y procesamiento
4. Límite de tamaño del paquete de datos
5. Secuestro y almacenamiento en caché
6. Obtener correctamente el tamaño del paquete de recursos
4.5 Optimización de la lógica de negocios
1. Simplifique la lógica: intente actualizar el contenido con interacciones complejas utilizando logotipos. Por ejemplo, hicimos una prueba en la versión anterior de QQ móvil: si tengo 100 amigos, me lleva 3,5 minutos iniciar sesión con QQ móvil y actualizar la lista de amigos. Esto ciertamente no es razonable. Se recomienda utilizar el estado de señalización para notificar si se necesitan actualizaciones y utilizar el caché de forma adecuada. Ahora, por ejemplo, si juegas un juego, tus amigos te darán muchas estrellas. ¿Quiere que los usuarios realicen pedidos todos a la vez o al por mayor? Desde una perspectiva de optimización, definitivamente es un punto por lotes, que es más cómodo desde la perspectiva de la experiencia del usuario.
Por otro lado, ampliar el tiempo de caché del icono del nombre de dominio también puede optimizar eficazmente el número de visitas. Después de ampliar el tiempo de caché de los iconos móviles de Tencent de 120 minutos a dos días, el número de visitas se optimizó en casi un 35%.
2. Uso flexible: esto significa que cuando la calidad de la red es buena, se mostrarán imágenes grandes de alta definición. Cuando la calidad de la red no sea buena, a los usuarios se les mostrarán primero las imágenes pequeñas y luego harán clic. para sacar la imagen original. Para poner un ejemplo extremo, por ejemplo, durante un terremoto, el 20% de la estación base queda dañada y el usuario quiere informar a su familia que está a salvo. En este momento, el producto debe optimizarse, como enviar solo texto, reducir razonablemente 3 y reducir el consumo de red. Además, cuando la respuesta es lenta, el usuario debe recibir algunas indicaciones de página razonables, como recordarle que envíe la página en 5 segundos y que no siga deslizando el dedo por la pantalla. Esto también puede reducir el impacto del acceso en segundo plano. servicios y la red.
Dicho todo esto, aquí te dejamos un ejemplo para ayudarte a comprenderlo de forma más intuitiva.
A continuación se muestra un diseño del sistema DNS para lograr una programación óptima. Su topología es la siguiente:
Responsabilidades de TGCP SDK:
1 Obtener la mejor lista de puntos de acceso del servidor y del propio DNSvr a través del método HTTP Get/Post. Los parámetros de consulta del método Get/Post incluyen uin/openid, número de versión del cliente, MD5 de la lista de IP (tenga en cuenta el orden de IP), lista de nombres de dominio, VIP, ServiceID, etc.
2. Almacene en caché la lista de IP del servidor de acceso y DNSvr, así como otros metadatos (como lista de IP, etc.), con APN como clave principal.
3. En algunos casos, debe actualizar activamente la lista de IP almacenadas en caché, como la caducidad de la caché.
Responsabilidades de Tconnd:
1. Enrutar solicitudes de consulta a DNSvr activo.
Responsabilidades de DNSvr:
1. Las políticas determinan el "mejor punto de acceso" del cliente. Política estática: determina la lista de IP según uin/openid, número de versión del cliente o reglas obligatorias; política dinámica: lighthouse determina dinámicamente el punto de acceso al servidor del usuario según los datos de medición de velocidad.
2. Soportar ataques manuales o automáticos a algunas IP. Modo automático: el tconnd de acceso del servidor informa a DNSvr si está activo (es necesario informar varios puntos, incluida la IP pública). Si no se recibe ningún informe dentro de un cierto período de tiempo, o está claro en el mensaje del informe que todos los servidores lógicos han sido suspendidos, la IP correspondiente se bloqueará automáticamente. Si se restablece el servicio, la IP correspondiente se activará automáticamente. Si el equipo del proyecto accede a TGW, se debe considerar la relación de mapeo entre procesos y VIP para determinar si una determinada IP y puerto están disponibles.
3. Almacene en caché los resultados del cálculo de lighthouse en tcaplus. En este momento, DNSvr necesita determinar el país, la provincia, el operador y la puerta de enlace en función de la IP del cliente (lo que se puede lograr accediendo a la biblioteca de IP de MIG). Si los resultados del cálculo del faro se almacenan en caché, los datos correspondientes deben extraerse del faro nuevamente después de que se agote el tiempo de espera del caché.
Las responsabilidades del faro:
1. Según la IP del cliente y la IP del punto de acceso del servidor, devolver la lista de puntos de acceso óptimos, incluido el orden de las IP y el número de clientes. Puntos de acceso. País, provincia, operador, APN, puerta de enlace.
Responsabilidades de Tcaplus:
1. Guardar listas de IP y puertos a los que se accede, políticas estáticas o almacenar en caché los resultados de los cálculos del faro;
Procesos principales:
p >Proceso de resolución de nombres de dominio por lotes del cliente
1. TGCP utiliza APN y la lista de nombres de dominio como caché de consultas de palabras clave. Si existe y no ha caducado, la IP se devuelve directamente al usuario. Si especifica una lista de nombres de dominio de resolución forzada, omita este paso;
2. TGCP utiliza una IP preconfigurada o almacenada en caché para enviar una solicitud de consulta a DNSvr. Si el resultado es exitoso, continúe con el paso 3. De lo contrario, vuelva a intentarlo con otras IP en la lista de IP. Si todo lo demás falla, utilice el nombre de dominio para acceder a DNSvr. Nota: Si el formato del resultado es incorrecto, vuelva a intentarlo con la última IP o vuelva a intentarlo sin cambiar la IP.
3.DNS VR compara el MD5 de la lista de IP del cliente con la última lista de IP. Si son iguales, le dice al cliente que no es necesario actualizar el caché local. De lo contrario, TGCP escribirá localmente la lista de IP que acceden al servidor y DNSvr. NOTA: Al acceder al servidor, estas IP tienen mayor prioridad que las IP configuradas estáticamente en el cliente.
Usar el cliente del nombre de dominio para acceder al proceso del servidor
1 Si hay una IP válida localmente (es decir, hay una lista de IP correspondiente al APN y ésta). no es válido), luego use la IP para acceder al servidor.
2. De lo contrario, después de iniciar el "proceso de resolución de nombres de dominio por lotes del cliente", acceda nuevamente al servidor.
Proceso de informe de estado del plan tconnd de acceso al servidor:
1. Tconnd informa periódicamente mensajes de latido a DNSvr, que contiene información sobre si el punto de acceso está disponible.
2. Si 2. DNSvr no recibe el mensaje de latido dentro de un cierto período de tiempo o el punto de acceso correspondiente no está disponible, la IP y el puerto correspondientes serán pirateados y la IP pirateada no se enviará. hasta el final del cliente.
Nota: Durante el proceso de implementación real, el tconnd al que se accede debe informarse a varios DNSvr que acceden a Tconnd.
El proceso de enviar activamente la lista de puntos de acceso al cliente
1. Cuando TGCP se conecta al Tconnd al que accede el servidor, Tconnd necesita enviar una solicitud a DNSvr para verificar el Dirección IP actual. Calidad y puntualidad. Si la lista de IP cambia, Tconnd enviará la lista de IP más reciente al cliente para su almacenamiento en caché.
2. La próxima vez que TGCP acceda al servidor, utilizará la lista de IP más reciente.
El cliente no pudo acceder a DNSvr.
1. Si falla el acceso a DNSvr (incluido IP + nombre de dominio), si se configura una IP local, use la IP para acceder al servidor directamente; de lo contrario, use el nombre de dominio para acceder.
Optimizar el diseño del protocolo de la capa de transporte
Basado en el UDP confiable admitido por el tconnd original, se agrega la siguiente lógica:
1. ;
2. Cifrado de datos;
3. Fusionar múltiples paquetes de datos;
4. Admite transmisión de datos para facilitar el control del tamaño de cada paquete UDP. y facilitar el cifrado y la compresión de datos;
5. Soporte opcional para un algoritmo de control de congestión mejorado
6. Incluso si no se recibe ningún paquete ACK, debe volver a intentar enviar paquetes de datos;
5.2 Algunas optimizaciones en desarrollo híbrido
Para hacer frente a la velocidad de carga en redes débiles, primero debemos determinar dónde está cargada toda nuestra aplicación y dónde está la ruta de carga más larga, para que podemos tener modificaciones de optimización específicas.
5.2.1 Vista web
Si se trata de una página de vista web integrada en una APP, ha pasado mucho tiempo para optimizar la experiencia web. Podemos usar el modo de desarrollador de Chrome, ajustarnos al modo de red, configurar la condición de red en 3G para solicitar una página web y luego podremos ver dónde se gasta principalmente la velocidad de carga de una página web, como se muestra en la siguiente figura:
Por supuesto, hay muchas formas de mejorar la velocidad de HTML.
1. Utilice gulpgrunt para empaquetar y comprimir: compresión de recursos jscss, fusión de Sprites CSS, etc.
2. Utilice la fuente Niubi en lugar de imágenes: las fuentes pueden ser muy compatibles, ampliadas infinitamente y hay disponibles imágenes de uso común.