One of the complexities of a CDN (Content Delivery Network) is to accurately determine the user’s geographical position. There has been a significant improvement in the use of conventional positioning methods on DNS servers in recent years, but these methods are still not sufficiently accurate, and implementing a stable and integrated structure would face some challenges. ArvanCloud employs Anycast technology to tackle this problem.
Anycast is a method for addressing and routing. In this method, the same IP address is allocated to a group of server nodes which, within a CDN framework, act as a series of servers in different datacenters throughout the world. The traffic sent to this IP address is responded by the topologically closest server to the transmitter of the request. As a result, ArvanCloud IP addresses are simultaneously advertised worldwide, and every user can connect to the closest edge server and get services through the first connection.
ArvanCloud is among a few global CDNs which operates in an integrated way not only on the DNS anycast layer but also based on Anycast routing (BGP Anycast). In this section, conventional routing methods are reviewed first. Then, the anycast routing method is analyzed along with its advantages.
For years, the Internet architecture allowed information (data) to exist only on a single server, which was responsible for responding to all information requests. Such a routing architecture is called unicast. This architecture has two serious problems:
These problems led to the development of a solution called anycasting.
There are three common methods for traffic routing and addressing:
In this case, every system has a unique IP address in the network, and a transmitter sends a specific message matching the IP address of a recipient. In the unicast architecture, no two devices can have the same IP address. Global communications are largely based on unicasting.
In this method, a message is broadcast to an address, and every device existing in the architecture can receive the message even if they have no need for it. Routers forward no IP packets to broadcast destinations in this approach.
In this method, a series of devices become the members of a group, to which a multicast address (a range of reserved addresses) is allocated. Now, all of the member devices can receive the traffic sent from a transmitter to the multicast group address. A widely-used instance of this method includes audio and video casting networks on the Internet.
Anycast routing is not a different routing protocol. It requires no specific capabilities on servers, user systems, or even other pieces of equipment. In fact, anycast is a configuration mechanism. Like unicasting, there are one-to-one links in anycast. In other words, a message is sent by a transmitter to a specific IP address, which has not been reserved for broadcasting or multicasting purposes. In fact, it is an ordinary public address.
Unlike unicasting, the single IP address is allocated to a group of devices rather than just one device. Thus, the allocation of the same address to two or more devices poses no problems in the anycast architecture. As a result, servers of the same IP address can exist worldwide. Each of them is responsible for responding to the users existing in their proximities.
For instance, assume that a specific web service can be provided through three servers in different parts of the world (or a network):
According to this figure, the user-side router determines all access routes to servers through 10.10.5.1 along with the distance and saves them in the routing table. Whenever a user sends a packet to 10.10.5.1, it will be routed through the shortest route.
Anycast routing can be implemented through all routing protocols. It is implemented through the BGP routing protocol on a CDN. For this purpose, server addresses are advertised to the Internet routers through BGP messages, and every router determines its distance from that address. As a result, if users intend to use a specific web service on the Internet, they connect to the closest server and receive the requested information.
Responding to user requests through closer servers can reduce the delay in data access.
With anycast, instead of a single server, there will be multiple distributed servers worldwide. If one server fails, the next closest server will automatically respond to user requests.
Anycast can be employed to place multiple servers in an area to load balance the traffic sent and received by the users existing in that area.
Anycast can be used to distribute a large amount of traffic sent by botnet-affected devices among anycast nodes. Thus, it will be possible to prevent the inaccessibility of a server due to inability to respond to the large number of requests.
With the help of anycast routing, the Internet routers will be able to deal with the problem of user access to web servers through the closest route possible. Therefore, there will be no practical problems in the use of certain methods such as the DNS protocol (caching DNS packets in user-side systems).
Now that anycast routing is introduced, a common question arises for the CDN users:
“The IP address of web services using ArvanCloud CDN exists in the Netherlands. Does it mean that the traffic of all users using these services (even Dutch users) will move abroad and be responded by foreign servers?”
The answer is negative. A technical case is analyzed to clarify the problem. As discussed earlier, a specific address is allocated to multiple servers worldwide in the anycast routing configuration. These servers are hereinafter referred to as ArvanCloud edge servers. Now assume 18.104.22.168/24, which is an ArvanCloud anycast IP address range, purchased from Germany and registered to that country. Nevertheless, purchasing an IP range from a specific country does not necessitate using the addresses in the same country. In the following figure, www.arvancloud.com should be accessible through CDN edge servers at 22.214.171.124 within an anycast framework.
According to this figure, 1126.96.36.199 is allocated to all edge servers and will be advertised to adjacent routers. If a user from anywhere in the world selects Arvancloud as the service domain, DNS servers translate the domain into 188.8.131.52. As discussed earlier, the Internet routers direct users toward the closest server. Thus, if a user from New York (In the United States) intends to visit www.arvancloud.com, the relevant data will be received from ArvanCloud edge servers in New York. Likewise, if users are located in Manchester, England, they will obviously be directed toward ArvanCloud edge servers in London. Hence, the edge server can be located anywhere in the world, including New York, to respond to requests for 184.108.40.206.
Finally, it is concluded that translating a domain into a foreign IP address (in Germany in this case) through DNS servers does not mean that the corresponding server must be located in that country and that the traffic is directed abroad.