Content Delivery Network (CDN) is a distributed Network composed of edge node server farms distributed in different regions, which is established and covered on the Internet. These high-performance service nodes store your service content according to certain cache policies. When a user sends a request to a service content, the request is dispatched to the service node closest to the user, and the service node directly responds to the request, effectively reducing the user access delay and improving the availability.
CDN effectively solves the following problems at the network level in current Internet services:
- The physical distance between the user and the service server is long, requiring multiple network forwarding, resulting in high transmission delay and instability.
- The carrier used by the user is different from the carrier where the service server resides.
- The service server has limited network bandwidth and processing capability. When a service server receives a large number of user requests, the response speed and availability decrease.
Antecedents feed
Systematically learn computer basics and blog about them. Our teaching materials are computer Networks (the original book 7th edition) (Douban), video explanation of the full set of computer networks (top-down method 7th edition, James F.Kurose, Keith W.Ross) by Zheng 烇 and Yang Jian
Computer Networking: Fundamentals of the Internet (I)
Computer Networks: Fundamentals of the Internet (PART 2)
Computer Networks: Application Layer protocol principles
HTTP will know and will know
What you should know about DNS – computer networks from top to bottom
This article describes the APPLICATION layer OF CDN in chapter 2.
Video streaming services and CDN
As we all know, video business is the killer application of Internet traffic, which accounts for more network traffic and can attract users the most. According to statistics, in the Internet, 7 ~ 8 percent of the traffic is video traffic.
The sheer volume of video traffic also poses two challenges to the modern Internet.
Challenge 1: Scale — how do you deliver simultaneous playback to thousands of people?
In the original Internet, video business is not a lot, open a few servers, to provide users with dozens of concurrent, or even hundreds of concurrent, can be said to be no problem at all. But there are so many users of video services on the Internet now, how can we ensure that we provide good video services to so many users?
Challenge 2: Heterogeneity — different users have different capabilities
For example, some users have wired access, some users have mobile access, some users have abundant bandwidth, and some users have limited bandwidth. It can be said that the video processing capacity of each node is also different, and the demand is also different.
Just like mobile users, the video resolution is relatively small; TV users, on the other hand, require higher resolution.
So what’s the solution? The distributed, application-level infrastructure — Content Distribution Network (CDN) is used to accelerate the Network.
Let’s take a look at how CDN solves the Internet killer application, Let’s go!
video
We can think of video as a sequence of images displayed at a fixed speed, which means that each video is made up of images. We know that the retina has a retention effect, and that the brain creates continuity in the world in the form of tween animation.
frame
Reference: What is the frame rate in the real world? – zhihu
We’re pretty used to watching videos or shows that play at 24 to 30 frames per second. Films shot on film are shot at 24 frames per second. This means that 24 images flash into your eye every second, a process called “visual persistence” in which the human eye automatically imagines the image between two frames.
Compression technology
That is, we can think of the video as a sequence of images, while a digital image is an array of pixels, each pixel represented by several bits.
So what are the characteristics of online video?
- High bit rate, high network bandwidth requirements
- Can be compressed
- More than 90% of Internet traffic is video
As we all know, video service occupies a very large bandwidth. Therefore, during the transmission of video in the network, it is usually compressed and converted into a video with a small bit rate.
What is the technique of compression?
The number of encoded bits is reduced by using redundancy within and between images, which is divided into spatial redundancy within images and temporal redundancy between adjacent images.
In the picture above, there are frames I and I +1.
Spatial redundancy: In frame I, each red dot represents a pixel point. You can see that in every frame these pixels are the same color, or similar color, and we call this spatial redundancy.
So, we can send only two data, the color (purple) and the number of repeats (N), which is how many pixels a pixel value lasts.
Time redundancy: Frame I +1 is the next frame of frame I. Frame I +1 has a lot of similarities to frame I, and we call that time redundancy.
So, instead of sending the entire encoding of frame I +1, only the bits that differ from frame I are sent.
Based on these characteristics of video, we can compress the video transmitted over the network to a small bit rate.
Compression standard
And there are many standards of compression:
- Constant Bit Rate (CBR) : Codes at a fixed rate
With CBI’s standard compressed video, bit rates are basically from a few hundred kilobytes to 2 meters, and do not change. So if the video is a static landscape, the amount of transmission is very, very small. But if the video switches scenes frequently, the bit loss rate becomes high and Mosaic can occur.
- Variable Bit Rate (VBR) : The video encoding rate changes with time
And this encoding type will encode at the resolution that you want. Why are there different resolutions? Because different video terminals have different requirements, like if your phone is small, 800 x 600 is enough. But if it is a PC, the resolution requirements are much higher.
The video stream
Streaming is a service we often use when we watch videos on the Internet.
When we watch a video, we load the content as we watch it, rather than downloading the entire video at once.
Download and play at the same time, the downloaded video is placed in the buffer, and the following video is directly extracted from the buffer and played continuously. This kind of streaming service can greatly reduce the user’s waiting time.
Dynamic,Adaptive Streaming over HTTP
DASH is a common protocol for streaming services, which stands for Dynamic adaptive HTTP Streaming. (You can see that HTTP is not only used for the Web, but also for downloading files and playing audio and video. HTTP is just a transport protocol, application-independent.
So what is dynamic adaptive fluidization?
The server
-
The video file is divided into multiple blocks, and a large video is cut into smaller pieces.
-
Each block is stored independently, encoded at different bit rates (8-10), and each block has a different resolution and encoding standard.
- Each block can be stored on a different server, either a source server or a cache server.
-
Manifest file: Describes how many pieces the video is cut into and what the URL of each piece is.
The client
-
To get the video, get the manifest file
-
Then, periodically measure the bandwidth from the server to the client
-
Query the notification file to request a block at a time. The HTTP header specifies a range of bytes
- If the bandwidth is sufficient, choose the video block with the maximum bit rate
- At different times in the session, you can switch between requesting different blocks of code (depending on the bandwidth available at the time)
That is, the client is “intelligent”, determined by the client’s adaptation to the following three conditions:
- When to request blocks: ensure that the cache does not starve or overflow
- Request what encoding rate video blocks: request high quality video blocks when bandwidth is sufficient
- Where to request blocks: can you send urls to servers close to you, or to servers with high available bandwidth
A media file is segmented and encoded at different bit rates or spatial resolutions. These fragments are then placed on a Web server that can be downloaded by the client via an HTTP standards-compliant GET request.
Server: As illustrated in the picture, the HTTP server provides three different quality services, namely Low, Medium, and Best, divided into equal length segments.
Client: Performs per-segment bit rate or resolution adaptation based on Bandwidth. For example, clients can switch to higher bit rates on a per-segment basis if bandwidth allows.
This technology, which we call DASH dynamic adaptive HTTP streaming, addresses the needs of different clients and the capabilities of different networks.
How to deploy it?
The question then becomes, how do we deploy these segments so that servers can stream video content to millions of users simultaneously over the network?
Solution 1: Service Center “Mega-Server”
Some students may say, this is not simple, directly deployed on a server is not ok. If so, it will be a giant superservice center.
But what are the problems if everyone gets streaming services from one or very few servers?
When the server runs into problems, the first thing you might think is that I’m not trying hard enough.
So the server keeps improving its service capacity, upgrading the network card, and upgrading the access bandwidth of the surrounding network. However, it does not work because the number of hops on the server-to-client path is too high and the bandwidth of the bottleneck link is too small to cause pauses. The server can optimize itself, but not the network.
Therefore, it is not enough to rely on the efforts of the server, and its own efforts cannot solve the problem of streaming server playback quality.
Secondly, the “Eight laws of Peking Road” determine that the network is filled with multiple copies of the same screen at the same time, causing a large amount of repeated traffic and serious waste of transmission resources in the network.
Moreover, there are problems of single point of failure reliability, performance bottleneck and network congestion around the whole server farm.
From what has been mentioned above, we can come to the conclusion that this method is quite simple, but not extensible.
Scheme 2: CDN
Therefore, there is the CDN content delivery network, which solves the problem of providing streaming services to a very large number of users with a single server (super service cluster), and it can provide better services to users.
So, how does CDN solve the problem?
The idea is simple: deploy many CDN nodes in the global network and pre-deploy some content to these cached nodes.
When a user visits, he does not necessarily get streaming video content from the source server, but is redirected through domain name resolution to the nearest cache node that provides him with the best quality of service (if the network path is congested, he may choose a different copy), thus improving the user experience.
We call it a content accelerated service.
If the user accesses content that is already deployed in these cache nodes, the user can be redirected through domain name resolution to find the cache node nearest to the user.
CDN services are provided by CDN operators, such as Lanxun and Qiniuyun.
CDN node deployment policy
We now know that CDN needs to deploy a lot of cache nodes around the world, so how to deploy these nodes?
There are two main methods: Enter deep (left) and Bring Home (right).
Enter deep, which deeps the CDN server into many access networks. The idea is to deploy many cache nodes within the scope of many local ISPs and pre-deploy some content to this cache node.
In this deployment mode, more nodes are deployed close to users. In this mode, users have fewer hops when requesting resources, and the network bandwidth is large. But because the deployed nodes are so far down, you need to deploy a very large number of nodes that are difficult to manage.
Another approach is bring Home, which is deployed on a small number of (10 or so) location-critical nodes. For example, a cluster of servers is installed near a POP (Internet service provider Point of Presence), close to several tier 1 ISP POP locations. In some upper ISPs, there are many key nodes of data center rooms, and I choose the location close to those key data center rooms.
In this way, as long as I get stuck in these key areas, I can also provide some good service to the user.
Complete the process
Finally, let’s take a look at a complete case after CDN access to deeply understand its parsing process.
- When a terminal user (Guangzhou Telecom) sends a request to a resource under www.baidu.com, check whether the host file and DNS cache records exist.
- Sends a domain name resolution request to the Local DNS.
- Local DNS Checks whether the IP address of www.baidu.com is recorded in the cache. If yes, it is returned directly to the end user. If no, consult the authoritative DNS.
- When the authoritative DNS resolves www.baidu.com, the authoritative DNS returns the CNAME www.baidu.com corresponding to the domain name
- Domain name resolution requests are sent to the DNS scheduler of the CDN, and the best node IP address is assigned to the request based on the Local DNS information.
- Local DNS Obtains the resolved IP address returned by the DNS.
- The user obtains the resolved IP address and initiates access requests to the obtained IP address.
- CDN If the CDN has a cache corresponding to the IP address, the CDN is directly returned to the user.
- If there is no cache for that IP, the content is requested up the cache node or source until it is returned to the user.