This article is a summary of bang God’s article mobile App network optimization overview, the article also added some of their own understanding and expansion.

  • Speed: How can the speed of network requests be further increased?
  • Weak network: mobile terminal network environment changes at any time, often appear network connection is very unstable availability poor situation, how to maximize the fastest successful request in this case?
  • Security: How to prevent eavesdropping/tampering or impersonation by third parties and hijacking by operators without affecting performance?

For browser-based front-end development, the network part can do very few things, but for the client APP, the whole network request process is free control, can do a lot of things, many large apps have done a lot of network layer optimization for these three problems. Some new network layer protocols such as HTTP2 / QUIC are also optimized in these areas. Here is a summary of the common practices.

A speed

The normal flow of a network request is as follows:

  • 1. DNS resolution: Request the DNS server to obtain the IP address corresponding to the domain name.
  • 2. Establish a connection with the server, including TCP three-way handshake and security protocol synchronization process.
  • 3. After the connection is established, send and receive data and decode data.

There are three obvious optimizations:

  • 1. Use the IP address directly without the DNS resolution step.
  • 2. Do not re-establish a connection with each request, reuse the connection, or use the same connection all the time (long connection).
  • 3. Compress data and reduce the size of transmitted data.

What can we do at each optimization point in turn

1 DNS

The complete DNS resolution process takes a long time. It is cached from the local system first. If it is not cached from the nearest DNS server, it is cached from the main DNS server.

  • 1. The cache time is set too long, the domain name is not updated in time, and the setting is too short. A large number of DNS resolution requests affect the request speed.
  • 2, domain name hijacking, easy to be attacked by the middle man, or hijacked by operators, domain name resolution to a third party IP address, according to statistics, the hijacking rate will reach 7%.
  • 3. The DNS resolution process is not controlled, and the fastest IP address cannot be resolved
  • 4. Only one domain name can be resolved at a time.

In order to solve these problems, there will be a HTTPDNS, here is the iOS version to access the document HTTPDNS iOS client access to the document, the principle is very simple, is the work, do your own DNS through HTTP requests the background to get the IP address of the corresponding domain, the solution to all problems directly:

  • 1, domain name resolution and request separation, all requests directly use IP address, no DNS resolution, APP periodically request HTTPDNS server to update the IP address.
  • 2, through the signature and other ways to ensure the security of HTTPDNS requests, to avoid hijacking.
  • 3. DNS resolution is controlled by itself, which ensures that the nearest IP address is returned based on the location of the user or the fastest IP address is used based on the client speed measurement result.
  • 4. Multiple domain names can be resolved in one request.

The rest of the details won’t go into detail, HTTPDNS has so many advantages that it’s almost standard for medium and large apps. This solves the first problem – DNS resolution time problem, incidentally part of the security problem – DNS hijacking also solved.

2 the connection

The second problem, the connection establishment time problem, here the main optimization idea is to reuse the connection, do not have to re-establish each request connection, how to reuse the connection more efficiently, can be said to be the most important point in the network request speed optimization, and the optimization is still in the process of evolution, it is worth understanding.

keep-alive

The HTTP protocol has keep-alive, which is enabled by default in HTTP1.1 to alleviate the time required to establish a TCP three-way handshake for each request. After the request is completed, the connection is not released immediately, but is put into the connection pool. If there is another request to be sent at this time, the connection in the connection pool is directly taken out to send and receive data, reducing the connection establishment time.

** In fact, keep-alive is now enabled by default on both the client and the browser, and there is no longer a situation where the same domain name will be established every time it makes a request. Pure short connections no longer exist. ** The problem is that the keep-alive connection can only send and receive one request at a time and cannot accept new requests until the previous one has been processed. If multiple requests are made at the same time, there are two cases:

  • 1. If the request is sent serially, it can always reuse a connection, but the speed is very slow, each request has to wait for the last request to complete before sending.
  • 2, if you send these requests in parallel, then for the first time each request to the TCP three-way handshake to establish a new connection, while the second can reuse this pile of connections in the connection pool, but if the connection pool to keep connection too much, to the service side, all have great waste of resources, if the limit to keep the number of connections, parallel requests beyond the connection still to build even at a time.

The new generation protocol HTTP2 proposes multiplexing to solve this problem.

multiplexing

HTTP2 allows you to connect multiple requests to the same network, but it allows you to connect multiple requests to the same network at the same time.

HTTP1.1 uses pipelining to process multiple requests at the same time. The pipelining protocol is used to process multiple requests at the same time. However, the response is still returned sequentially in the order of the request. If one of the requests has a slightly larger response or an error occurs, the subsequent requests will be blocked.

The HTTP2 multiplexing protocol solves these problems by encapsulating the data transmitted through the connection into a stream, each stream is identified, and the stream can be sent and received out of order, independent of the order, so there is no blocking problem. The receiver can distinguish which request belongs to according to the stream identifier, and then perform data splicing to obtain the final data.

Just to explain the word multiplexing, multiplexing can be thought of as multiple connections, multiple operations, and multiplexing literally means multiplexing one connection or one thread. HTTP2 multiplex connection multiplexing, network related to the I/O multiplexing (SELECT /epoll), refers to an event-driven way to allow multiple network requests to return data in the same thread to complete the read and write.

For clients, iOS9 above NSURLSession native support HTTP2, as long as the server also support can be directly used, Android OKHTTP3 above also support HTTP2, some large domestic APP will build their own network layer, support HTTP2 multiplexing, Avoid system restrictions and according to their own business needs to add some features, such as wechat open source network library Mars, do a long connection to handle most requests on wechat, multiplexing characteristics basically consistent with HTTP2.

The TCP queue header is blocked

HTTP2 multiplexing seems to be the perfect solution, but there is also the problem of queue header blocking, which is limited by TCP. TCP guarantees data reliability by waiting for a lost TCP packet to be retransmitted before processing subsequent packets. The multiplexing of HTTP2 makes all requests run on the same connection, and if one packet is lost, it blocks waiting for retransmission, and all requests are blocked.

For this problem, TCP cannot be optimized without changing the TCP protocol. However, TCP relies on the implementation of the operating system and the customization of part of the hardware, and the improvement is slow. Therefore, GOOGLE proposes QUIC protocol, which is equivalent to defining a set of reliable transmission protocol on top of UDP to solve some defects of TCP, including queue head blocking. QUIC protocol is based on UDP, but it not only has TCP reliability, congestion control, flow control, etc., QUIC protocol relative to HTTP2 is the biggest advantage of THE TCP queue blocking solution, in addition, QUIC protocol has TLS security transmission features, to achieve the TLS confidentiality function, At the same time, fewer RTTS are used to establish secure sessions.

3 data

The third problem is the size of the transmitted data. The impact of data on request speed is divided into two aspects, one is the compression rate, the other is the speed of decompression serialization deserialization. Currently, the two most popular data formats are JSON and Protobuf. Json is a string, protobuf is binary, which means a protobuf is still smaller than JSON when compressed using various compression algorithms. Protobuf has an advantage in terms of data volume. Serialization speed Protobuf also has some advantages, but the comparison between the two will not be detailed. See this article protobuf in action on iOS to learn more about Protobuf

The latest Brotli and Z-Standard achieve a higher compression rate. Z-standard can train suitable dictionaries based on business data samples to further improve the compression rate. Currently, the best compression rate algorithm.

HTTP headers are usually repeated data, and fixed fields such as method can be used in static dictionaries. Fields that are not fixed but have multiple repeated requests, such as cookies, can achieve very high compression rates with dynamic dictionaries, as described here.

With HTTPDNS, connection multiplexing, and better data compression algorithms, the speed of network requests can be optimized to a good degree. Let’s look at what can be done on weak networks and security.

The second network weak

Mobile phone wireless network environment is unstable, for weak network optimization, wechat has many practices and shares, including:

  • 1, improve the success rate of connection compound connection, connection establishment, step type concurrent connection, one connection after the other connections are closed. This scheme combines the advantages of serial and concurrent to improve the connection success rate under weak network, while not increasing server resource consumption:
  • 2. Set the most appropriate timeout period. Set different calculation schemes 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 try again as soon as possible. The timeout period can also be set dynamically according to the network status.
  • 3. Tune TCP parameters and use TCP optimization algorithm. The TCP protocol parameters of the server are tuned and various optimization algorithms are enabled to adapt to the service characteristics and mobile network environment, including RTO initial value, mixed slow start, TLP, F-RTO and so on

These meticulous optimization for weak network has not become the standard, the system network library is not built, but the first two client optimization wechat open source network library Mars has been implemented, if necessary can be used.

Three security

The standard protocol TLS ensures the security of network transmission. The predecessor of TLS is SSL, and it is constantly evolving. At present, TLS1.3 is the latest. HTTPS is the COMMON HTTP protocol plus TLS security protocol.

Security protocols generally solve two problems: 1. Ensure security; 2. Reduce the cost of encryption

In ensuring safety:

  • 1. Use the combination of encryption algorithms to encrypt the transmitted data to avoid eavesdropping and tampering.
  • 2. Authenticate the identity of the other party to avoid being impersonated by a third party.
  • 3. The encryption algorithm remains flexible and can be updated to prevent the fixed death algorithm from being cracked and cannot be replaced, and disable the cracked algorithm.

Reduce the cost of encryption:

  • 1. Encrypt transmitted data with symmetric encryption algorithm to solve the problem of low performance and length limitation of asymmetric encryption algorithm.
  • 2. Cache the data such as the key after the handshake of the security protocol to speed up the second connection establishment.
  • 3, speed up the handshake process: 2RTT-> 0RTT. The idea of accelerating the handshake is that the client and server need to negotiate which algorithm to use to encrypt and send data. Instead, they use the built-in public key and default algorithm to send data at the same time of the handshake, that is, they do not need to wait for the handshake to start sending data, reaching 0RTT.

These points involve very much detail, the introduction of TLS has a male article, said very detailed, in this recommendation.

At present, the basic mainstream support TLS1.2, iOS network library default use TLS1.2, Android4.4 support 1.2. TLS1.3 iOS is still in the test phase, Android has not checked the message. For common apps, TLS1.2 can ensure transmission security as long as the certificate is correctly configured, but there will be loss of connection speed in construction. Some large apps like wechat have implemented part of the TLS1.3 protocol by themselves, which is supported by all platforms earlier.

The last

Bang’s article gave me a deeper understanding of the network layer, a more comprehensive understanding of every detail in the network request process and how to optimize. As Bang said, network optimization is a huge topic, which is just the tip of the iceberg of network optimization