Common problems and optimization strategies for mobile networks

When we start to pay attention to the user experience of App, network connectivity and interface fluency are important indicators to ensure the usability of App. Recently, I conducted a simple analysis of the network data in the project and conducted research on some solutions in the industry, so I wrote this article to sort out the knowledge.

When we use an App, if we often encounter loading failures or the App keeps spinning in circles, it is likely that there is a problem with the App's network performance, and R&D personnel are urgently needed to optimize it. For developers, it is very difficult to locate network problems, because the users who have network problems are often far away, and you cannot debug and locate them. Therefore, it is very important to establish a complete network monitoring system to accurately locate network problems through the analysis of massive data.

[[249368]]

Through data analysis, research, and user feedback, we found that mobile networks often have the following problems:

• The network success rate is low and requests often fail.
• Users reported DNS hijacking, data tampering, ads, and request timeouts.
• The network delay is long and there is a lot of long-tail data
• After data analysis, it was found that the time of long connection was significantly less than that of short connection by about 100ms (short connection refers to the establishment of connection through a series of processes such as DNS resolution, TCP handshake, SSL handshake, etc., while long connection refers to the direct reuse of the former connection channel)
• The network often jitters. Most requests are around 100ms, but suddenly there are 1,000 to 2,000 milliseconds, or even 10 to 20 seconds of delay.
• HTTP 1.1 has a head of blocking problem. A network jitter can easily affect subsequent requests, resulting in a series of requests with high latency (head of blocking: in HTTP 1.1, if you send three network requests 1, 2, and 3, the response order 2 and 3 must be after the first network request)
• The transmitted payload is too large, the latency is high, and it is easy to time out.
• Apple requires HTTPS, and the SSL handshake added at this time is more time-consuming

There are many solutions to the above problems in the industry. I will briefly list some of them here.

How to solve this problem in the face of such a network?

In the case of DNS hijacking, the main approach in the industry is HTTPDNS or built-in Server IP list. The client directly accesses the HttpDNS interface to obtain the IP with the lowest access delay configured by the business on the domain name configuration management system. After obtaining the IP, the business protocol request is directly sent to this IP, without the need to use the local operator to resolve the domain name, so the hijacking problem is fundamentally avoided, and the network delay can be reduced and the connection success rate can be increased. The establishment of a Server IP list is to cache an IP mapping table locally. This table can be dynamically issued and updated when the App is started, and the IP is directly used to send a request when accessing the server.

The transmitted payload also directly affects the delay and the success rate. For data compression, many companies in the industry have begun to use the ProtoBuf protocol. I have not yet accurately concluded the optimization percentage, but from everyone's feedback, the optimization effect is obvious. For data compression, you can also consider accessing HTTP 2.0. After all, this is a trend. Many companies have also joined HTTP 2.0. HTTP 2.0 also helps you reduce the transmitted payload through header compression and other methods.

Many of the above questions actually involve the issue of long and short connections. There are many questions that can be considered for this issue.

• Domain name merging: Taobao, Meituan and other companies have announced plans to merge the company's many domain names into fewer domain names. Why do they do this? HTTP channel reuse is based on domain name division. If there are only a few domain names, most requests can be made on the long connection channel, which can reduce latency and increase success rate.
• Establish a persistent connection as early as possible so that other business requests can reuse the persistent connection channel to speed up access. For the timing of establishing a connection, you can consider multiple aspects, such as cold start, front-end and back-end switching, network switching, etc.
• Consider using HTTP2.0 . Both of them solve the head of blocking of HTTP 1.1, reduce network latency, provide more powerful multiplexing technology, and add flow control, new binary format, Server Push, request priority and dependency features. Or use SPDY, but I think it is more appropriate to use HTTP 2.0 directly.
• Establish multiple channels . For example, companies such as Ctrip and Meituan have their own TCP and UDP channels, which have multiple domain name shared channels and a success rate of 99.99. At the same time, major manufacturers are also trying new network protocols, such as QUIC. Facebook also shared an improvement on QUIC to achieve 0-RTT of TLS.

There are some other points to consider.

• Add CDN acceleration and separate dynamic and static resources
• For buried data, you can also merge requests to reduce traffic
• App Network Diagnostics
• Dynamically set timeouts based on network conditions, etc.