As mentioned in the previous lecture, there are three links that can be optimized in the entire HTTP system, namely server, client and transmission link (“first mile” and “The middle kilometer”). But because we cannot fully control the client, the actual optimization work is usually done on the server side. This can be subdivided into back-end and front-end. The back-end refers to the background service of the website, and the front-end is the code and data displayed on the client such as HTML, CSS, and images.
Now that we know the general direction, how should we specifically optimize HTTP performance?
In general, the optimization of any computer system can be divided into several categories: hardware and software, internal and external, and whether to spend money or not.
Invest in ready-made hardware The simplest way to optimize, such as replacing it with a stronger CPU, faster network card, greater bandwidth, and more servers, the effect will be “immediate” and directly improved. The service capability of the website also realizes HTTP optimization.
In addition, Spending money to purchase external software or services is also an effective optimization method. The most “value for money” should be CDN (see Lecture 37). CDN focuses on web content delivery, helping websites solve the “middle mile” problem, and has many other very professional optimization functions. Handing over the website to a CDN is like “putting the website on a jet plane”. It can reach users directly and achieve good optimization results with almost no effort.
However, these methods of “spending money” are really not “technical” and belong to the practices of “lazy people” (no derogatory meaning), so I won’t go into details. Next, I will focus on the internal and “unskilled” aspects of the website. Spend money” on software optimization.
Summarize this aspect of HTTP performance optimization into three keywords: Open source, throttling, caching.
Open source
This “open source” is not Open Source, but refers to grasping the “source”, developing the potential of the website server itself, and trying to tap out more service capabilities while the existing conditions remain unchanged.
First of all, we should choose a high-performance web server. The best choice is of course Nginx/OpenResty. Try not to choose other servers based on Java, Python, and Ruby. They are better used for the subsequent business logic servers. Utilize Nginx’s powerful reverse proxy capability to achieve “dynamic and static separation”. Dynamic pages are handed over to Tomcat, Django, Rails, and static resources such as pictures and style sheets are handed over to Nginx.
Nginx or OpenResty itself also has many configuration parameters that can be used for further tuning. To give a few examples, such as disabling load balancing locks, increasing connection pools, binding CPUs, etc., there is a lot of related information.
In particular, long connections must be enabled for the HTTP protocol. As you also saw in Lecture 39, the cost of establishing a new connection for TCP and SSL is very high, and may account for more than half of the total client delay. Although long connections cannot optimize the connection handshake, they can “average” the cost over multiple requests, so that only the first request will be delayed, subsequent requests will not have connection delays, and the overall delay will be reduced.
In addition, the new TCP feature “TCP Fast Open” (Win10, iOS9, Linux 4.1) is already supported on modern operating systems. Its effect is similar to TLS’s “False Start” and can be used during the initial handshake. Data is transmitted when the data is transmitted, which is 0-RTT, so we should enable this feature in the operating system and Nginx as much as possible to reduce the handshake delay between the external network and the internal network.
A brief Nginx configuration example is given below, which enables optimization parameters such as long connections and achieves dynamic and static separation.
server {
listen 80 deferred reuseport backlog=4096 fastopen=1024;
keepalive_timeout 60;
keepalive_requests 10000;
location ~* \.(png)$ {
root /var/images/png/;
}
location ~* \.(php)$ {
proxy_pass http://php_back_end;
}
}
Throttling
“Throttling” refers to reducing the amount of data sent and received between the client and the server, so as to transmit more content within the limited bandwidth.
The most basic method of “throttling” is to use the “data compression” encoding built into the HTTP protocol. Not only can you choose the standard gzip, but you can also actively try new compression algorithms br, which has better compression effects.
However, when compressing data, you should pay attention to choosing an appropriate compression ratio, and do not pursue the highest compression ratio. Otherwise, it will consume the server’s computing resources, increase response time, and reduce service capabilities, which will result in “more gain than loss.”
Gzip and br are general compression algorithms. For various formats of data transmitted by the HTTP protocol, we can also use special compression methods in a targeted manner.
HTML/CSS/JavaScript is pure text, so you can use special “compression” to remove redundant spaces, line breaks, comments and other elements in the source code. Although the text after such “compression” looks messy and unfriendly to “humans”, the computer can still read it without any hindrance and does not affect the running effect of the browser.
Images account for a very high proportion in HTTP transmission. Although they have been compressed and cannot be processed by gzip and br, there is still room for optimization. For example, remove metadata such as shooting time, location, and model from the picture, appropriately reduce the resolution, and reduce the size. The format of the image is also very important. Try to choose a format with high compression rate. The lossy format should use JPEG, and the lossless format should use Webp format.
For small text or small pictures, there is another optimization method called “Concatenation”, which is to merge many small resources into one large resource, download them all to the client with one request, and then the client uses JavaScript and CSS The advantage of using it after splitting is that it saves the number of requests, but the disadvantage is that the processing is more troublesome.
The several types of data compression just mentioned are all aimed at the body in the HTTP message. There is no way to compress the header in HTTP/1, but we can also take some measures to reduce the size of the header, and try not to send unnecessary fields. (e.g. Server, X-Powered-By).
Websites often use cookies to record user data. The browser will bring cookies every time it visits the website, which is highly redundant. Therefore, cookies should be used sparingly to reduce the amount of data recorded by cookies. Always use the domain and path attributes to limit the scope of cookies and reduce the transmission of cookies as much as possible. If the client is a modern browser, you can also use Web Local Storage defined in HTML5 to avoid using cookies.
In addition to compression, there are two optimization points for “throttling”, namely domain name and redirection.
DNS resolution of domain names will take a lot of time. If a website has multiple domain names, then domain name resolution to obtain IP addresses is a big cost. Therefore, domain names should be appropriately “shrunk” to about two or three to reduce the time required to resolve complete domain names. The required time allows the client to obtain the parsing results from the system cache as soon as possible.
The client delay caused by redirection is also very high. It not only adds a request round trip, but may also cause DNS resolution of a new domain name, which is a “big taboo” for HTTP front-end performance optimization. Unless necessary, you should try not to use redirects, or use the web server’s “internal redirects”.
Caching
In Lecture 20, we talked about “caching”. It is not only HTTP, but also the “magic weapon” for performance optimization of any computer system. Combine it with the “open source” and “throttling” above and apply it to the transmission link. It can take the performance of HTTP to another level.
In the “zero mile”, that is, inside the website system, special caching services such as Memcache, Redis, and Varnish can be used to store the intermediate results and resources of calculations in memory or hard disk. The web server first checks the cache system. If there is data It is returned to the client immediately, saving the time of accessing the background service.
In the “middle mile”, caching is an important means of performance optimization. The network acceleration function of CDN is based on caching. It can be said that if there is no caching, there will be no CDN.
The key to making good use of the cache function is to understand how it works (see Lectures 20 and 22), add ETag and Last-modified fields to each resource, and then use Cache-Control and Expires to set the cache control properties.
The most basic of these is the max-age validity period, which marks the time the resource can be cached. For static resources such as images and CSS, you can set a longer time, such as one day or one month. For dynamic resources, unless the real-time nature is very high, you can also set a shorter time, such as 1 second or 5 seconds.
In this way, once the resource reaches the client, it will be cached, and no more requests will be sent to the server during the validity period, that is: “Requests without requests are the fastest requests.
“HTTP/2
In addition to the three major strategies of “open source”, “throttling” and “caching”, there is another option for HTTP performance optimization, which is to upgrade the protocol from HTTP/1 to HTTP/2.
Through the study of “Flying Chapter”, you already know many advantages of HTTP/2. It eliminates head-of-line blocking at the application layer, and has many new features such as header compression, binary frames, multiplexing, flow control, server push, etc. feature, which greatly improves the transmission efficiency of HTTP.
In fact, these features are also based on the two points of “open source” and “throttling”, but because these are already built into the protocol, as long as HTTP/2 is replaced, the website can immediately obtain significant performance improvements.
However, you should note that some optimization methods in HTTP/1 will have “counterproductive effects” in HTTP/2.
For HTTP/2, a domain name can only obtain the best performance by using one TCP connection. If you open multiple domain names, it will waste bandwidth and server resources, and also reduce the efficiency of HTTP/2, so “domain name shrinking” is used in HTTP /2 is a must.
“Resource merging” reduces the cost of multiple requests in HTTP/1, but in HTTP/2 due to header compression and multiplexing, the cost of transmitting small files is very low, so merging is meaningless. Moreover, “resource merging” has another disadvantage, which is that it reduces the availability of the cache. As long as a small file is updated, the entire cache will be completely invalid and must be downloaded again.
Therefore, in today’s high-bandwidth and CDN application scenarios, resource merging (JavaScript, CSS image merging, data embedding) should be used as little as possible, so that the granularity of resources is as small as possible, so that the role of caching can be better utilized.
Summary
Spending money to purchase hardware, software or services can directly improve the service capabilities of the website, the most valuable of which is CDN;
You can optimize HTTP without spending money. The three key words are “open source”, “throttling” and “caching”;
The backend should use a high-performance web server, enable long connections, and improve TCP transmission efficiency;
The front end should enable gzip and br compression, reduce the size of text and images, and transmit as few unnecessary header fields as possible;
Caching is a performance optimization tool that should not be forgotten at any time. Resources should always be marked with the Etag or Last-modified field;
Upgrading to HTTP/2 can provide immediate performance improvements in many areas, but be aware of some HTTP/1 “anti-patterns”.
