Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what is the working mode of HTTPDNS". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Problems existing in traditional DNS Domain name caching

When the client wants to access a URL, in fact, the first thing is to see if there is this address in the local cache, if so, it will visit directly, and if not, it will ask the superior.

But at this time, there will be a problem: for example, when Ah Fan was in high school, I knew there was a delicious restaurant next to the school. later, when A Fan wanted to eat again, he didn't even think about it, but went directly to that store, only to find that he was closed. At that time, A Fan was very disappointed.

Similarly, this problem will also occur in the local cache. Sometimes the address has been changed, but because there is the original address in the local cache, you will not be asked at a higher level to direct you to the original address. As a result, you cannot access the interface. The resulting user experience is not very good.

There is another problem: suppose I am in Haidian District, Beijing, and the Taobao app does not set up a data center in Haidian District for some reason, and then when I visit, I always send my access request to Chaoyang District. Later, Taobao added a data center in Haidian District, but when I visited, the local cache still directed my request to Chaoyang District. The result is:

For the client, it's a long detour. It is obvious that things that can be solved in one region have to be cross-regional. Just like you can buy something here, but let you go to another place to buy, are you happy?

For merchants, that is, Taobao, I set up a new data center, and as a result, the customer's request did not come here, so why did I bother to do it? It does not improve the user experience, whether it is right.

Export NAT problem

At the gateway, many computer rooms will configure NAT (Network Address Translation) at the exit, that is, network address translation.

In other words, all packets going out of this gateway will be replaced with a new IP address. When the request is returned, the IP address will be translated back at the gateway. As a result, the authoritative DNS server cannot determine which operator the user is from by this address, and it is very likely that the misjudgment of the operator will lead to cross-operator access, resulting in extremely slow network speed.

Analytical delay problem

In the query process of DNS, it is necessary to recursively traverse multiple DNS servers to get the final parsing result, which will bring a certain delay or even parsing timeout.

The working mode of HTTPDNS

There are a lot of problems with DNS parsing, so what should I do? Back to the original starting point: direct IP address? It's obviously not appropriate.

This leads to HTTPDNS. To put it bluntly, it does not follow the traditional DNS parsing, but builds its own DNS server cluster based on HTTP protocol. These clusters are distributed in multiple locations, and when the client needs DNS parsing, the nearest address can be obtained by requesting the server cluster directly through the HTTP protocol. This is equivalent to each client is based on the HTTP protocol, their own domain name resolution, make their own address book, instead of using a unified address book.

But the default domain name resolution is DNS, so if you want to use HTTPDNS, you need to bypass the default DNS path, so you can't use the default client.

People who use HTTPDNS are generally mobile applications, so you only need to embed SDK, a client that supports HTTPDNS, on the mobile side to OK. In this way, through our own HTTPDNS server and related SDK, we can change from relying on others to querying on the Internet, where we want to go and what we want to do. Isn't it fast?

The working mode of HTTPDNS can be described as follows: when the phone wants to access an address, I will first see if there is any in the local cache. If so, the cache is done by the mobile application itself. As for how and when to update, it is the business of the client of the mobile app. If not, you need to request the HTTPDNS server. In the IP list of the local HTTPDNS server, select a request to send HTTP, and it will return an IP list of websites to visit. Because it is direct HTTP communication, so the HTTPDNS server can know this information accurately, so it can achieve accurate global load balancing.

At this point, this article is trying to express two points:

Traditional DNS has many problems, such as domain name cache, export NAT, resolution delay.

In order to solve the above problems, HTTPDNS calls the parsing DNS directly through the client SDK and the server, in the form of HTTP, which bypasses these shortcomings of the traditional DNS and realizes intelligent scheduling.

This is the end of the content of "how HTTPDNS works". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.