Overview of Mobile APP Network Optimization Processing

Generally, when developing an APP, you will directly call the network request interface provided by the system to request data from the server, and then perform some processing on the returned data, or use a network library such as AFNetworking/OKHttp to manage request threads and queues, and then automatically perform some data parsing, and that's it.

However, for some large apps, we may want to further optimize some network issues, including:

1. Speed: How can the speed of network requests be further improved?
2. Weak network: The mobile network environment changes at any time, and the network connection is often very unstable and has poor availability. How can we maximize the fastest success of the request in this case?
3. Security: How to prevent eavesdropping/tampering or impersonation by a third party and hijacking by operators without affecting performance?

For browser-based front-end development, there is little that can be done with the network. But for client apps, the entire network request process is freely controllable and a lot of things can be done. Many large apps have made a lot of network layer optimizations for these three problems. Some new network layer protocols like HTTP2/QUIC have also made a lot of optimizations in these aspects. Here I will learn and organize them, and roughly list the common practices.

speed

The normal process for a network request is as follows:

• DNS resolution, request the DNS server to obtain the IP address corresponding to the domain name.
• Establish a connection with the server, including the TCP three-way handshake and security protocol synchronization process.
• Connection establishment is complete, data is sent and received, and data is decoded.

There are three obvious optimization points here:

• Use IP addresses directly, eliminating the DNS resolution step.
• Do not re-establish a connection for each request, reuse the connection or always use the same connection (long connection).
• Compress data to reduce the size of transmitted data.

Let’s look at what can be done one by one.

1. DNS

The complete DNS resolution process is very long. It will first retrieve the domain name from the local system cache. If it is not available, it will go to the nearest DNS server. If it is not available, it will go to the primary domain name server. Each layer has a cache, but in order to ensure the real-time nature of domain name resolution, each layer of cache has an expiration time. This DNS resolution mechanism has several disadvantages:

If the cache time is set too long, the domain name will not be updated in time; if it is set too short, a large number of DNS resolution requests will affect the request speed.

Domain name hijacking is easily attacked by a man-in-the-middle or hijacked by an operator, who resolves the domain name to a third-party IP address. According to statistics, the hijacking rate can reach 7%.

The DNS resolution process is uncontrolled and cannot guarantee the fastest IP resolution.

Only one domain name can be resolved at a time.

In order to solve these problems, HTTPDNS was created. The principle is very simple. It does the domain name resolution work by itself, and obtains the IP address corresponding to the domain name through HTTP request backend, which directly solves all the above problems:

Domain name resolution is separated from requests. All requests use IP addresses directly without DNS resolution. The APP can periodically request the HTTPDNS server to update the IP address.

Through signature and other means, the security of HTTPDNS requests is guaranteed to avoid hijacking.

DNS resolution is controlled by yourself, which can ensure that the nearest IP address is returned based on the user's location, or the fastest IP is used based on the client's speed test results.

Multiple domain names can be resolved in one request.

I won’t go into the rest of the details, HTTPDNS has so many advantages that it has almost become the standard for medium and large APPs. So far, the first problem - the time-consuming DNS resolution problem has been solved, and part of the security problem - DNS hijacking has also been solved.

2. Connect

The second problem is the time-consuming connection establishment. The main optimization idea here is to reuse the connection without re-establishing the connection for each request. How to reuse the connection more efficiently can be said to be the most important point in network request speed optimization, and the optimization here is still in the process of evolution, it is worth understanding.

keep-alive

There is a keep-alive feature in the HTTP protocol, which is enabled by default in HTTP1.1. It alleviates the time consumption of TCP three-way handshake to establish a connection for each request to a certain extent. The principle is that the connection is not released immediately after the request is completed, but is put into the connection pool. If there is another request to be sent at this time, and the requested domain name and port are the same, the connection in the connection pool is directly used to send and receive data, which reduces the time consumption of establishing a connection.

In fact, keep-alive is now enabled by default in both the client and the browser. For the same domain name, there will no longer be a situation where a connection is established for each request. Pure short connections no longer exist. However, there is a problem, that is, this keep-alive connection can only send and receive one request at a time, and new requests cannot be accepted before the previous request is processed. If multiple requests are initiated at the same time, there are two situations:

If you send requests serially, you can reuse a connection all the time, but the speed is very slow, and each request must wait for the previous request to complete before sending.

If these requests are sent in parallel, each request will have to perform a three-way TCP handshake to establish a new connection for the first time. Although the connections in the connection pool can be reused the second time, if there are too many connections in the connection pool, it will cause a large waste of server resources. If the number of connections maintained is limited, the connections that exceed the limit in parallel requests will still need to be established each time.

To solve this problem, the new generation protocol HTTP2 proposed multiplexing.

Multiplexing

HTTP2's multiplexing mechanism is also to reuse connections, but the connection it reuses supports processing multiple requests at the same time. All requests can be performed concurrently on this connection, which solves the problem mentioned above that concurrent requests need to establish multiple connections. There is a picture on the Internet that can more vividly show this process:

In the HTTP1.1 protocol, data is transmitted in a connection in serial order. The next request can only be processed after the previous request is fully processed. As a result, the connection is not fully transmitted during these requests. Even though HTTP1.1's pipelining can send multiple requests at the same time, the responses are still returned serially in the order of the requests. As long as the response of one of the requests is slightly larger or an error occurs, the subsequent requests will be blocked.

The multiplexing protocol in HTTP2 solves these problems. It encapsulates the data transmitted in the connection into streams. Each stream has an identifier. The sending and receiving of the stream can be out of order and does not depend on the order, so there will be no blocking problem. The receiving end can distinguish which request it belongs to based on the stream identifier, and then splice the data to get the final data.

Explain the word multiplexing. Multiplexing can be considered as multiple connections, multiple operations, and multiplexing is the literal meaning, multiplexing a connection or a thread. HTTP2 is the multiplexing of connections. There is also an I/O multiplexing (select/epoll) related to the network, which means that the data returned by multiple network requests can be read and written in the same thread in an event-driven way.

For the client, NSURLSession of iOS9 and above natively supports HTTP2, and can be used directly as long as the server also supports it. Android's okhttp3 and above also support HTTP2. Some large domestic apps will build their own network layer to support HTTP2 multiplexing to avoid system limitations and add some features according to their own business needs. For example, WeChat's open source network library mars can handle most requests on WeChat with one long connection, and the multiplexing feature is basically the same as HTTP2.

TCP Head-of-Line Blocking

HTTP2 multiplexing seems to be a perfect solution, but there is still a problem, which is head-of-line blocking. This is limited by the TCP protocol. In order to ensure data reliability, if a TCP packet is lost during transmission, the TCP protocol will wait for the packet to be retransmitted before processing subsequent packets. HTTP2 multiplexing allows all requests to be processed on the same connection. If a packet is lost in the middle, it will be blocked waiting for retransmission, and all requests will be blocked.

This problem cannot be optimized without changing the TCP protocol, but the TCP protocol relies on the implementation of the operating system and the customization of some hardware, and its improvement is slow. Therefore, Google proposed the QUIC protocol, which is equivalent to defining a reliable transmission protocol on top of the UDP protocol to solve some defects of TCP, including head-of-line blocking. There is a lot of information on the specific solution principle on the Internet, which you can take a look at.

QUIC is in its infancy and has few client access. The biggest advantage of the QUIC protocol over HTTP2 is the solution to TCP head-of-line blocking. Other optimizations such as secure handshake 0RTT/certificate compression have been followed up by TLS1.3 and can be used in HTTP2. They are not unique features. How much impact TCP head-of-line blocking has on the performance of HTTP2 and how much speed improvement QUIC can bring remains to be studied.

3. Data

The third question is the size of the transmitted data. The impact of data on request speed is divided into two aspects: one is the compression rate, and the other is the speed of decompression, serialization and deserialization. The two most popular data formats are json and protobuf. json is a string, and protobuf is binary. Even after compression using various compression algorithms, protobuf is still smaller than json. Protobuf has an advantage in data volume and serialization speed. I will not go into details about the comparison between the two.

There are many different compression algorithms, which are also constantly evolving. The latest Brotli and Z-standard achieve higher compression rates. Z-standard can train a suitable dictionary based on business data samples to further improve the compression rate. It is currently the algorithm with the best compression rate performance.

In addition to the transmitted body data, the data in the HTTP protocol header of each request cannot be ignored. HTTP2 also compresses the HTTP protocol header. Most HTTP headers are repeated data. Fixed fields such as method can use a static dictionary, and non-fixed but repeated fields in multiple requests such as cookies can use a dynamic dictionary, which can achieve a very high compression rate. A detailed introduction is here.

Through HTTPDNS, connection multiplexing, and better data compression algorithms, the speed of network requests can be optimized to a better level. Next, we will look at what can be done in terms of weak networks and security.

Weak network

The mobile phone wireless network environment is unstable. WeChat has many practices and sharing for the optimization of weak networks, including:

Improve connection success rate

Composite connection, when establishing a connection, a ladder-like concurrent connection is used, and after one of the connections is connected, the other connections are closed. This solution combines the advantages of serial and concurrent, improves the connection success rate under weak network conditions, and does not increase server resource consumption:

Develop the most appropriate timeout period

Different calculation schemes are formulated for the total read and write timeout (timeout from request to response), first packet timeout, and packet timeout (timeout between two data segments) to speed up the judgment of timeout, reduce waiting time, and retry as soon as possible. The timeout here can also be set dynamically according to the network status.

• Tune TCP parameters and use TCP optimization algorithms.
• Tune the TCP protocol parameters on the server side and enable various optimization algorithms to make them suitable for business characteristics and mobile network environment, including RTO initial value, hybrid slow start, TLP, F-RTO, etc.
• These detailed optimizations for weak networks have not become standards, and the system network library does not have them built in. However, the first two clients have been optimized in the WeChat open source network library mars, and can be used if needed.

Safety

The standard protocol TLS ensures the security of network transmission. Its predecessor is SSL, which is constantly evolving. The latest one is TLS1.3. The common HTTPS is the HTTP protocol plus the TLS security protocol.

Security protocols generally solve two problems: 1. Ensure security 2. Reduce encryption costs

In terms of ensuring safety:

1. Use a combination of encryption algorithms to encrypt transmitted data to prevent eavesdropping and tampering.
2. Verify the other party's identity to avoid being impersonated by a third party.
3. The encryption algorithm remains flexible and updatable to prevent the fixed algorithm from being cracked and unable to be replaced, and to disable the cracked algorithm.

Reducing encryption costs:

1. Use symmetric encryption algorithms to encrypt transmitted data to solve the problems of low performance and length limitation of asymmetric encryption algorithms.
2. Cache the key and other data after the security protocol handshake to speed up the second connection establishment.
3. Speed ​​up the handshake process: 2RTT-> 0RTT. The idea of ​​speeding up the handshake is that the client and the server originally need to negotiate which algorithm to use before encrypting and sending data. Now they use the built-in public key and the default algorithm to send data at the same time as the handshake, that is, they can start sending data without waiting for the handshake, achieving 0RTT.

These points involve a lot of details. There is a great article introducing TLS, which explains it in great detail. I recommend it here.

Currently, most mainstream platforms support TLS1.2. The iOS network library uses TLS1.2 by default, and Android 4.4 and above support 1.2. TLS1.3 is still in the testing stage for iOS, and no news has been found for Android. For ordinary apps, as long as the certificate is configured correctly, TLS1.2 can already ensure transmission security, but there will be some loss in connection speed. Some large apps like WeChat have implemented some TLS1.3 protocols on their own, and have supported all platforms one step ahead.

at last

The topic of network optimization is very large. This article only lists the common optimization points in the industry from the perspective of optimization ideas during the learning process. There are still many details and more in-depth optimizations that are not involved. The practical development experience of the network layer is insufficient. If there are any errors, please point them out.