Programación de nombres de dominio y resolución de nombres de dominio
Los nombres de dominio son fáciles de recordar, pero las direcciones IP no. Esto demuestra lo importante que es el servicio DNS.
Dns no sólo puede resolver IP desde el nombre de dominio. También puede analizar la mejor IP en función de la ubicación geográfica del cliente. ¿Cómo entender esto? Por ejemplo, si visito Baidu.com en Shenzhen, el servidor DNS resolverá la dirección IP de la sala de computadoras más cercana en lugar de permitirme acceder a la sala de computadoras en Beijing.
Esto es el equilibrio de carga global del servidor (GSLB). Porque, para garantizar la alta disponibilidad de las aplicaciones de servicio, a menudo se implementan varias salas de computadoras y cada lugar tendrá su propia dirección IP. Cuando un usuario accede a un nombre de dominio, estas direcciones IP pueden sondear estas salas de ordenadores. Además, en la medida de lo posible, esperamos que los usuarios de Beijing vayan a la sala de computadoras de Beijing y los usuarios de Shanghai vayan a la sala de computadoras de Shanghai. De esta forma, la experiencia del cliente será muy buena y la velocidad de acceso será rápida.
GSLB y SLB aparentemente perfectos. De hecho, hay muchos problemas.
Dado que hay tantos problemas con el DNS tradicional, ¿cómo solucionarlos?
Sí, es HTTPDNS
HTTPDNS no utiliza la resolución DNS tradicional, sino que construye su propio clúster de servidores DNS basado en el protocolo HTTP, que se distribuye en múltiples ubicaciones y operadores. Cuando un cliente requiere resolución DNS, solicita este clúster de servidores a través del protocolo HTTP. a la dirección más cercana.
Sin embargo, las aplicaciones móviles que utilizan HTTPN a menudo necesitan integrar un SDK de cliente que admita HTTPN en el teléfono móvil.
Solicite dinámicamente al servidor en el SDK del cliente para obtener la lista de servidores HTTPDNS. Almacenamiento en caché local Con resolución continua de nombres de dominio, el SDK también almacenará en caché los resultados de la resolución de nombres de dominio DNS localmente.
Cuando una aplicación quiere acceder a una dirección, primero comprueba si hay un caché (este caché lo crea la propia aplicación móvil, no el caché del operador, por lo que cómo actualizarlo está bajo su propio control). ). Si no hay caché local, se solicita HTTPDNS desde el servidor. Por supuesto, el cliente móvil sabe a qué operador y dirección se envía el pago. Debido a que es una comunicación HTTP directa, HTTPDNS también puede devolver mejor información de resultados y lograr un mejor equilibrio de carga global.
En el cliente podrás conocer la información de ubicación geográfica exacta del operador. HTTPDNS puede devolver el mejor nodo de servicio según esta información.
Si hay varios nodos, también consideraremos la tasa de error, el tiempo de solicitud, la presión del servidor, las condiciones de la red, etc. para hacer una selección completa. En lugar de simplemente considerar la ubicación. Cuando un nodo falla o el rendimiento se degrada, cambie lo antes posible.
En el lado del servidor, el servidor puede configurar diferentes pesos y prioridades de calidad del servicio, contar, analizar y resumir la tasa de error, el tiempo de solicitud, la calidad de la solicitud y otros datos informados por el cliente, para ver los servicios de diferente calidad IP.
Para no distorsionar la programación, el cliente puede almacenar en caché diferentes dimensiones según el SSID de los WIFI de diferentes operadores de redes móviles. Los resultados de diferentes operadores o WIFI serán diferentes.
El 1 de abril de 2016, Google lanzó oficialmente el servicio de consulta de seguridad de nombres de dominio DNS-Over-HTTPS.
Este servicio admite los siguientes parámetros:
Hay un problema en Edns_client_subnet. Por ejemplo, si tiene necesidades en el extranjero, debe enviar el nombre de dominio cname a proveedores de CDN famosos en el extranjero, como fastly y akamai. Debe determinar si el proveedor de CDN reconoce la extensión EDNS. Por ejemplo, la autoridad de Akamai negó que Alibaba haya acudido a Tencent Cloud. Parece que la autoridad recae en Tencent Cloud.
Comprueba si hay algún resultado del análisis.
Referencia 1. La época geek de Liu Chao.
2./windyf 2013/article/details/79727348