Proper length
Interviewer: A brief introduction to CDN and its effect on the front end
A: A CDN is a Content Delivery Network. Deploying front-end resources in a CDN can speed up the client’s access to resources.
Interviewer:… All right, go back and wait for word
A: Don’t…
Interviewer: Tell me why CDN can speed up the client’s access to resources
A: as shown in figure
There are multiple edge node servers in CDN network. After we upload the resources to the source server (usually the business server for business deployment), the resources in the source server can be deployed to each edge node server through the central scheduling of THE CDN network. The client can obtain the required resources from the nearest edge node server, which physically shortens the distance of resource transmission and speeds up resource acquisition.
Interviewer: So it must be faster to get resources from the CDN than from the business server?
A: Of course not. In this case, for example, when a client requests a certain resource to CDN for the first time, the process is as follows:
-
The client queries the IP address nearest to the CDN first
-
Once you have the IP address, make a resource request to the edge node server
-
The edge node server finds that it does not have the resource requested by the client and asks the source server for it
-
Steps 3 and 4 are called back to the source
-
Once the edge node server gets the resource, it caches a copy of it and sends the resource response to the client
-
Bingo, the client got the latest resource
As you can see, if you request resources back to the source, it will be slower than if the client accesses the source server directly. But once the edge node is cached, the second access is faster (because the edge node server is close to the client), as shown below
Interviewer: Since the edge node server has cache, how to ensure that the cached resources are the same as the source resources (i.e. if the source resources are updated, how can the client get the latest resources without delay)
A: Static resources such as JS and CSS packaged by the project can be named with hash files, such as vendor.hash1.js, when webpack is packaged. When a resource is updated, the name of the packaged resource changes: vendor.hash2.js; This ensures that resources with the same name are the same on both the source and edge node servers, as shown below (assuming the CDN domain name is cdn.example.com) :
Static resources such as JS and CSS are referenced by HTML (webpack can inject the latest resource paths into HTML), so as long as the HTML entry files accessed by the client are up to date, so are the rest of the static resources accessed
Interviewer: How do you ensure that the HTML entry files accessed by the client are up-to-date and also hash
A: The name of the entry file will not change. If the file is named with a hash, you will need to modify the redirection entry on nginx every time you update the HTML entry file. Suppose our system domain name is demo.example.com and the client accesses the system as follows:
Since the domain name is not changed when the client accesses the system, nginx listens to this request and takes the system entry file from the CDN and returns it to the client. However, nginx does not know the name of the entry file, which is configured by the operation staff. If the entry file is also named with hash, then nginx will need to configure the latest name to ensure that nginx requests the latest entry file from the edge server.
Therefore, in the edge node server, you can set the cache time of the HTML entry file to be very short, such as 5 minutes. After a few minutes, the cache will be exhausted and the edge node server will go back to the source to get the latest entry file resources (near real time for the client). For other static resources, the cache time can be set to a longer time to reduce the return to the source
Interviewer: How long is the cache time for other static resources appropriate? Is permanent ok
A: It is theoretically possible. For hash resources with the same name, the content is the same, and there is no difference between the source server and the edge node server with the same name. Therefore, a longer cache validity period reduces the probability of returning to the source.
However, the capacity of edge node servers is not infinite, and even if the server capacity is set to permanent, the oldest resources are usually deleted when the server capacity is full.
If the project has a stable iteration period, you can set the cache age based on the iteration period. Moreover, even if the resource expires, the edge node server does not immediately go back to the source, but decides whether to go back to the source by comparing some request parameters and looking at the filtering parameters
Interviewer: Would it be risky to cache HTML files for 5 minutes
A: There are… The HTML entry file is updated, which means that the system is updated, and the interface of the back-end service may also be updated. For example, the parameters passed in are changed. If the entry file accessed by the client is an old cache in the edge node server, the parameters passed in by the interface requested by the client are still old. If the back-end interface is not backward compatible, the system will not work normally, or even cause a blank screen (this is a PM spanking bug).
Interviewer: How can you avoid it?
Answer: EMMMMMmm, when THE HTML is updated, the CDN refresh function is used, in fact, the HTML cache in the edge node server is deleted, so that when the client request triggers the CDN back to the source, you can get the latest data. It’s just… It’s a little dangerous, maybe delete the wrong thing, is to cause a lot of back to the source, maybe the whole source server hung…
Interviewer: When a person is middle-aged, it is important to be steady. Isn’t there any other way
A: Yes, that is, HTML is not deployed in the CDN, deployed to a separate server, this server only provides access to HTML, no caching; Because the HTML files developed by SPA are now very small, the access speed is acceptable.
Interviewer: Consider this scenario: your product has a large number of users, and there will be a lottery next week. The lottery page is newly developed. Talk about how you can optimize the CDN to ensure the normal use of your lottery
A: Because the lottery page is newly published, that is, the edge node server does not have the cache of the lottery page resources, there may be a large number of CDN back sources when the lottery date arrives. In this case, you can use the CDN’s warm-up feature, which manually triggers the edge node server to request resources from the source server and cache them before the lottery date.
Interviewer: Preheating can only ensure that users can access the lottery page quickly (i.e. preheating can only preheat static resources), but the lottery operation and prize data still have to be sent to the server through Ajax requests. How to do if the server is destroyed
A: No panic. CDN also has the function of data prefetch. Operation and maintenance personnel can configure policies according to the correlation between the content accessed by users and the data, request some public data from the source server in advance and cache it. For example, when users visit the lottery page, they will definitely get the prize list and other data, which is the same for everyone. The CDN can request these data from the source server in advance and cache it, so that the client can reduce the number of requests to the business server.
In addition, at present, many CDN vendors provide some simple computing capabilities on edge node servers and can cache the calculation results, so that users can directly request edge node servers for some simple interactive operations, further reducing the pressure on business servers.
Interviewer: Yeah, that’s ok. Let’s talk about other front-end network optimization methods
Answer:…
Hire guest slogan
Welcome to pay attention to the wechat public number: front-end cutters, cutters ~ more front-end knowledge