Welcome to Tencent Cloud + community, get more Tencent mass technology practice dry goods oh ~
This post was posted by Mariolu in cloud + Community
HTTP/ 1.x does an excellent job of meeting the universal access requirements of the Internet, but as the Internet continues to evolve, its performance becomes more and more of a bottleneck. The IETF released the HTTP/2 standard in 2015, focusing on improving the HTTP access experience. The main advantages of HTTP2 include: binary transport, header compression, multiplexing and Server Push. To date, most CDN vendors have announced support for HTTP/2, but the “support” mostly omits the ServerPush feature. This is probably related to the fact that the open source version of NGINx does not support Server Push. To provide complete HTTP2 capabilities, Tencent CDN has now completed HTTP/2 Server Push support and completed detailed performance tests.
The preface
Before introducing the Server Push feature, let’s analyze the loading process of the website. Figure 1 is tencent classroom time waterfall figure (https://ke.qq.com/index.html).
A) First, the browser requests the main page index.html, and the server responds with the content;
B) After receiving the response from the home page, the browser begins to parse the HTML tag of the home page and finds that CSS, GIF, JS and other resources are needed to build the DOM tree;
C) Initiate content requests for CSS,GIF and JS;
D) Get and parse content such as JS and CSS, and then continue to request dependent resources.
FIG. 1 Time waterfall diagram of Tencent Classroom domain name
Figure 2 shows a simplified interaction between the browser and the server, with the horizontal axis representing the timeline and one RTT per dotted line. The red bar indicates when the DOM load is complete. As can be seen from the figure, although there is concurrent transmission, the home page index.html and its dependent resources common.css, 0684a8bf. CSS and com.nowrap.0b772fee.js are generally in sequence, and the waiting time for resource response slows down the loading speed of the home page. Concurrent transfers do not improve the resource access experience of serial resolution.
If the server receives the main request from the client, it can “predict” the dependent resources of the main request and actively push the dependent resources to the client concurrently when responding to the main request. After the client parses the response to the primary request, it obtains dependent resources from the local cache “without delay”, reducing access latency, improving access experience, and enhancing the link concurrency capability. Server Push is based on this principle to improve the web experience.
Figure 3 shows that if the server push function is adopted, JS/CSS resources can basically arrive at the same time as HTML resources. Browser can obtain JS/CSS resources “without delay”, and the delay of client can be reduced by at most one RTT.
Construct a simple example to verify our statement. The simple_push.html code is shown in Figure 4. The page relies on resources simple_push.js and simple_nopush.js. The page size is less than 1KB, and the main time is spent on transmission delay. Figure 5 shows the effect of pushing simple_push.js versus not pushing simple_nopush.js.
Figure 4 push test HTML code
FIG. 5 Effect comparison between no push and push
We launched a test demo web site (https://http1.gtimg.cn/push/mypush.html). The page shows a map of the world, made up of 400 small pictures. Compare the three access modes: HTTP/1.1, HTTP/2 (without Server Push), and HTTP/2 (Server Push). Server Push selects and pushes the 150-179 minigraphs in total. The comparison of access performance data is shown in Figure 6: It can be found that pre-push has certain performance improvement compared with no push (the result fluctuates due to the influence of network delay and client behavior, and will be analyzed in the following article).
Figure 6 demo site test
After a brief introduction to the optimization principle of Server Push, questions are raised: what resources to Push, how to Push, and what advantages are there compared with other optimization technologies? As you finish this chapter, these questions will be answered one by one. Finally, the article will demonstrate the application scenarios and performance optimization effects of Server Push with examples.
one
Push to realize
1. Identify dependent resources
W3C candidate recommendation (https://www.w3.org/TR/preload/) suggested that depend on the resources of two kinds of practice: tags and HTTP headers carried in the documents, said that the resource can be used, can advance request, keyword preload modify the resource, written as follows:
A) Static Link label method:
B) HTTP header representation:
Link: <push.css>; rel=preload; as=style
Where rel indicates that the resource </push.css> is preloaded and as indicates the file type of the resource. In addition, link can also be modified with nopush, indicating that the browser may have the resource cache, indicating that the server with push ability will not actively push the resource, only when the browser first checks that there is no cache, to instruct the server to push the resource, nopush format is written:
Link: </app/script.js>; rel=preload; as=script; Nopush.
2. Push resources
User access to CDN mainly includes edge nodes directly accessed, several intermediate nodes and customer source stations. Each layer in the path can analyze the request, predict the possible dependent resources, and return to the browser by inserting static labels or adding response headers. CDN push mainly adopts the header to carry push information.
A) The client assigns push resources
The client uses the URL or request header to specify the resource URL as follows:
Url：http://http2push.gtimg.com/simple_push.html?req-push=simple_push.js
Or:
GET/simple_push. HTTP / 1.1 HTML
Host: http2push.gtimg.com
The user-agent: curl / 7.49.1
Accept: /
X-Push-Url: simple_push.js
B) CDN nodes specify push resources
CDN nodes configure push resources for requested resources. The basic configuration is as follows:
The location ~ “/ simple_push. HTML ${“
http2_server_push_url /simple_push.js
}
C) The source station specifies push resources
The response header link is added to notify the client or CDN node of the subsequent dependent resources to be pushed. Nodes with push function (such as CDN nodes) can request and push resources based on this information.
3. Function realization
Figure 7 shows the Server Push architecture of CDN. The basic process is as follows:
A) After the user request reaches the server, the resource prediction module predicts the resources required by the browser according to the request header or configuration, and the url of the pushed resource must be the same host as the main request. The server refuses to push resources that do not belong to the same host.
B) The server uses PUSH_PROMISE frame to inform the browser of the resource path to be pushed. The message is sent on the original master request flow, and the master response must be sent first; otherwise, the browser may initiate dependent resource requests before the push resources arrive, resulting in repetition and waste.
C) Rely on the resource request module to construct the same request information as the main request, request push resources in the local or back-end server, and actively create a new HTTP/2 request flow. The subsequent server can send resource response, push resource response is transmitted on the stream created by the server, and the main page response is transmitted in the original stream.
FIG. 7 Transformation diagram of Server Push module of CDN
CDN nodes send push resources before the main request response, as shown in Figure 8, mainly based on the following factors:
D) Push resources are generally static resources with high cache hit ratio, such as JS, CSS, fonts and pictures. These resources can be pre-pushed from the source station and cached to the CDN node. In contrast, the main page changes a lot and needs to wait for network IO to fetch data from the source site. At the same time, the RTT of CDN edge node to browser is generally shorter than that of CDN node to source site. So there’s plenty of time to push resources before you get the latest response from the main page.
E) Resource push can detect and improve the TCP congestion window. The window gradually increases, and the subsequent response on the main page can be sent at one time. The effect of TCP congestion Windows on push is discussed in Section 3 below.
F) During the NETWORK IO time waiting for the response of the main request, push resources can have no priority relationship. The influence of resource push priority on push will also be discussed in the third part below.
Figure 8. Push time point before main page response
two
Server Push technology comparison
1. Vertical comparison
The specific promotion without Server Push is as follows:
A) Nopush loading time: Tnopush = RTT+ Max (RTT, size(HTML)/BandWidth)+size(JS)/BandWidth
B) Push time: Tpush = RTT + size(HTML)/BandWidth + size(JS)/BW
C) Improve efficiency: DIff = 1-Tpush /TnoPush
So the measurement factors that determine whether push improves performance are size(HTML/BandWidth) and RTT. BDP(bandwidth-delay product) is introduced here. BDP describes the amount of data that can be transmitted per unit of time. If size(HTML)<BDP, push is recommended; Otherwise, push is not recommended.
2. Horizontal comparison
HTTP/1.1 has Resource Inlining, which copies the contents of resources into HTML tags. For instance
Where 1.js calls the 2.js file, 3.js and 4.js do not call other js.
The normal load time table for unpushed examples would be
Figure 10 NoPUSH&push renderings of resource loading priorities
It can be seen that the loading priority of 1.js should be before 3.js and 4.js, but 3.js and 4.js are pushed in advance. However, 1.js needs to be requested again, and 2.js request is triggered, resulting in waiting for 1RTT to receive 2.js. So Push is less efficient than No Push.
Kernel buffer
The HTTP/2 request priority does not affect the data already in the kernel send buffer. If the size of the kernel send buffer is larger than that of the TCP congested serial port, the server sends low-priority data and the kernel buffer exists. Subsequent high-priority responses must wait for the kernel buffer to empty before they can be completed. Suppose we visit an HTML page, the HTML page needs to fetch data back to the source site, and the STATIC JS resources required by the HTML are cached on the EDGE node of the CDN. Static JS resources are sent to the browser during the waiting time at the source. If the static JS resource is large and fills the kernel send buffer, the HTML response has reached the CDN edge node and has to wait for space in the kernel buffer to continue sending. Link requests that wait for the browser to parse the HTML content are also delayed.
4. Browser cache
Pushing cached browser resources can take longer to load and waste bandwidth resources. A cached resource is pushed repeatedly, and without additional free bandwidth, the network will block its subsequent normal requests, dragging down the load time of the entire site.
four
Site test
We performed Server Push performance test on some web pages on the live network, because Push required HTTP/2 requests under the same domain name. In order to avoid interference caused by non-HTTP /2 and cross-name, we set up a proxy node. The proxy node completed HTTP/2 support and domain name collection, and configured the Server Push function. Look at page load revenue. In order to accurately test the network delay changes caused by Push, a stable network environment is required. Set the network environment mytest (RTT: 200ms, Download: 29Mb/s, Upload: 14Mb/s) in Chrome. The following examples are tested in this network environment.
1. Tencent News
In accordance with the applicable scenario described earlier push, use the tencent news page (https://news.qq.com/a/20171031/032143.htm) for testing. The main request page size is 11.6K. As can be seen, advance push JS, CSS, images and other resources to the client to bring faster website performance.
Figure 11. Tencent News page
FIG. 12 Comparison of no push & push on Tencent news page
2. Tencent Customer service
Tencent customer service page does not support HTTPS. The reason why this page is used is that the main request of this page is relatively small, and there are JS and CSS triggered secondary priority resource requests. We downloaded this web page, and did some necessary processing such as pushing resource domain name collection, and put it on the edge node of CDN for testing. This does not change the resource and request order of the site and does not affect the testing effect.
Figure 13 is the page of Tencent customer service. Figure 14 lists all the requests on Tencent’s customer service page. Let’s focus on the timeline for several specific cases: no push, push small files, push large files. Small file push pushes resources (tcss.ping.js, cdn_djl.js, layer.css) that can only be triggered by layer 3 requests to the browser in advance on the first RTT. Indexbanner.png is pre-pushed for the large file push.
From the subgraph of no push and 3 small files in Figure 14, the red dotted line indicates that the load completion time of indexbanner.png is not included. Due to the extraction push of the 3 small files (especially the sub-priority request Tcss.ping.js), the time delay is shorter than that of no push. However, it can be seen from the subgraphs of no push and large file push that pushing large file indexbanner.png (782KB) without priority is not helpful to shorten the delay of the website.
FIG. 13 Tencent customer service page
FIG. 14 Comparison of no push & push small files & push large files
five
conclusion
While the test cases in this chapter are just the tip of the iceberg for the vast web of the Internet, this article cannot cover a wide variety of web scenarios. But some of the suggestions below are practical.
1. Push appropriate resources at the right time. The delay of Push is significantly higher than that of No Push. On the premise that the network bandwidth is enough to carry the push resources, we push the resources required by the browser for subsequent requests in advance, thus shortening the overall loading time of the website. However, the real network environment has different latency and bandwidth. Slow networks affect the rate at which the TCP congestion window grows, and Push cannot see the effect unless the home page request is small enough.
2. Even if some push strategies are incorrectly implemented (such as pushing too large files), the most serious consequence is that the improvement is not obvious. So the advice is to experiment with push strategies until the right resources are pushed to the browser at the right time.
3. There is a trend for websites to migrate to HTTP/2 environments. Moving to HTTP/2 requires that all requests for the page be brought into the same domain as possible, and the resource files are stripped off the main page into multiple independent requests. If your site has migrated to HTTP/2 and the site’s main request is small, it may trigger many resource requests. It is recommended to push these resources. Also do not push resources stored in browser cookies, this will only waste bandwidth.
4. The current Server Push mechanism does not solve the problem that the browser already has resource cache, but the Server has pushed to the network. Although the browser can send RST frame to reject the Push stream, the resources pushed by the Server have been waiting for the browser to receive in the network. Now there are some specification draft (https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-01) try to use the cache to solve the problem through consultation.
5. The load balancing mechanism in CDN may send low-priority push resources to the system cache, which will affect the push efficiency of high-priority resources. By introducing QUIC to replace TCP, the resources pushed in the cache can be graded, and the resources with higher priority are sent first.
6. In the future, AI analysis may be introduced to replace fixed push to realize intelligent push.
Question and answer
How does Angular2 handle HTTP responses?
reading
How do I step by step find pressure measurement performance bottlenecks with GO
How to back up your MySQL database
This section describes the changes in MySQL 8.0
Has been authorized by the author tencent cloud + community release, the original link: https://cloud.tencent.com/developer/article/1159626?fromSource=waitui
Welcome to Tencent Cloud + community or follow the wechat public account (QcloudCommunity), the first time to get more mass technology practice dry goods oh ~
Massive technical practice experience, all in the cloud plus community!