1, the introduction

Network optimization is crucial to the user experience of mobile App products, and is closely related to the company’s operation and revenue.

Here are two public figures:

“57% of users leave after 3 seconds of page loading.”

“A one-second increase in Amazon page loading reduces Revenue by $1.6 billion a year.”

The impact of network performance on user experience is directly fed back to business operation.

Moreover, the inherent weak network problems, DNS problems, connection performance and so on of mobile network cannot compare with the traditional fixed network. Therefore, it is especially necessary to optimize the mobile network.

For instant messaging applications (IM), message, push the developers, whether short connection or long join optimization, can directly reflect on the experience of APP, surely unexpectedly IM or class IM applications are customers with the use of high frequency scene, network question on experience fact, users will be infinite amplification, so avoid nor is it the right way to solve the problem.

With that in mind, IM has compiled a number of articles (including this one) on mobile weaknets, hoping to give you some ideas on how to optimize your mobile network.

This article is simultaneously published in the “instant Messaging technology circle” public account, welcome to pay attention to:

2. The author of this article

Zhou Hui: Mobile technology expert of Meituan Dianping, head of mobile architecture. More than 10 years experience in mobile terminal development.

* Led and participated in the architecture design and business development of most of the company’s mobile client products;

* Joined the original Dianping in 2010, and now focuses on the development and maintenance of the underlying architecture of Meituan-Dianping client;

* In 2016, the mobile terminal communication architecture in charge won the company-level technology Breakthrough Award.

3. Related articles

Summary of Optimization Methods for Short Connections in Modern Mobile Networks: Request Speed, Weak Network Adaptation, and Security Guarantee

Mobile IM Developers must Read (1) : Easy to Understand the “weak” and “Slow” mobile Web (recommended)

Mobile IM Developers must Read (ii) : Summary of the Most Complete Mobile Weak Network Optimization Methods in history (recommended)

Comprehensive Understanding of mobile DNS Domain name hijacking and other miscellaneous diseases: Principles, Roots, HttpDNS Solutions, etc.

Mobile DNS Optimization practice of Meitu App: HTTPS Request Time Reduced by Nearly half

Baidu APP Mobile Terminal Network In-depth Optimization Practice Sharing (I) : DNS Optimization (recommended)

Baidu APP Mobile Terminal Network In-depth Optimization Practice Sharing (II) : Network Connection Optimization (recommended)

Baidu APP Mobile Terminal Network In-depth Optimization Practice Sharing (III) : Mobile Terminal Weak Network Optimization Chapter

Iqiyi Mobile Terminal Network Optimization Practice sharing: Network Request Success Rate Optimization (recommended)

“5G era has arrived, TCP/IP old, still can eat?”

Wechat Mars: A Network Layer encapsulation library being used inside wechat, to be Open Source

As promised: Mars, a cross-platform component library of mobile IM Network layer for wechat’s own use, has officially opened source

Optimizing login Requests for Mobile IM Development

“Tencent original Sharing (I) : How to greatly improve the mobile QQ picture Transmission speed and success rate under the Mobile Network”

“Tencent Original Sharing (II) : How to greatly reduce APP Traffic Consumption in mobile Network (Part II)”

Tencent original Sharing (iii) : How to greatly reduce APP traffic Consumption under mobile Network (Part I)

Introduction to Zero-Base Communication technology for IM Developers (11) : Why WiFi Signal is Bad?

Introduction to Basic Communication technology for IM Developers (12) : Access to network traffic? Network Down? Get it!

Introduction to Zero-Base Communication technology for IM Developers (13) : Why Cell phone Signal is Bad?

How hard is wireless Internet access on high-speed Trains?

4. Content Overview

How to prevent network traffic from being hijacked?

How to improve the user page opening speed?

What do you do when the boss feedback page doesn’t open?

Let’s take a look at the experience sharing in the network optimization practice of Meituan Dianping client.

In this article, you can learn about the attempts made by meituan-Dianping mobile architecture team to improve the quality of mobile communication, as well as a set of monitoring and communication solutions gradually developed, which will open new ideas for you to optimize the network communication quality of your App.

5. Current situation of the problem

Before we discuss solutions, what are the most common problems that occur during mobile web requests?

First, The Internet Is unavailable. It is mainly caused by the following reasons:

• 1) GFW interception, for reasons you understand;
• 2) DNS hijacking, port blocking, etc.;
• 3) Poor network infrastructure in remote areas.

Second, long loading time of the Network. These reasons include:

• 1) For the purpose of saving electricity, mobile devices need to preheat communication chips before sending network requests;
• 2) The network request needs to cross the network operator and the physical path is long;
• 3) HTTP request is based on Socket design, before the request is initiated, there will be three handshakes, and when disconnected, there will be four waves.

Last but not least: HTTP data security. Specific reasons are as follows:

• 1) HTTP data is easy to be captured;
• 2) The DATA in the Post packet is encrypted to avoid leakage, but the URL and header parts of the protocol are still exposed to the packet capturing software (HTTPS also faces a similar problem).
• 3) Serious data tampering by operators.

As shown in the picture below, an advertisement has been inserted into the webpage of the App by the carrier:

Of course, we are not imagining these problems. At Meituan Dianping, the monitoring team developed an end-to-end client monitoring platform. End-to-end is the process from the request sent from the client to the response returned from the server. It is different from background service monitoring, which is a real experience monitoring observed from the user’s perspective.

Through Meituan-Dianping’s monitoring tools, we can clearly see the various network reasons and proportion:

6. Short-link optimization scheme 1: domain name consolidation

In the face of the network problems mentioned in the previous section, we first tried some optimizations in HTTP short connection requests.

As the development scale gradually expanded, each service team applied for its own level 3 domain name for independence and stability.

There are more and more API domain names in App, as shown below:

search.api.dianping.com

ad.api.dianping.com

tuangou.api.dianping.com

waimai.api.dianping.com

movie.api.dianping.com

… .

After the number of domain names in the App increases, it will face the following problems:

• 1) HTTP requests need to establish connections with different servers, which increases the loss of the number of concurrent connections in the network;
• 2) Each domain name requires the DNS service to resolve the server IP address.

If you want to merge all the three-level domain names into one domain name, you will face a huge problem to promote the project. Since different business teams split up domain names for reasons of independence and stability, they are bound to encounter great resistance when trying to combine them again.

So here we are:

• 1) combine domain names;
• 2) Improve the efficiency of network connection;
• 3) It cannot transform the back-end service server.

After discussion, we came up with a compromise.

As shown in the figure above, the core idea of this solution is to keep the network requests written by the client’s business layer code consistent with those received by the back-end service Server. Before sending the requests, the domain names are compiled at the client’s network layer and sent to the back-end. The domain names are restored in Server Load Balancing (SLB).

For example: the URL “http:// ad.api.dianping.com/command?param1=123” in the underlying network is modified to api.dianping.com/ad/command?param1=123 “http://”.

Here, the domain name “ad.api.dianping.com” is replaced with “api.dianping.com”, and the domain name followed by “AD” indicates that this is a domain name request related to advertising business.

And so on, the domain names of all urls are merged into “api.dianping.com”. Subdomain name information is hidden in the path after the domain name.

For example: “http://api.dianping.com/ad/command?param1=123” was reduction in SLB for “http://ad.api.dianping.com/command?param1=123”. SLB is used to distribute requests to different business servers, and after domain name restoration, the request has been consistent with the original request in the client business code.

The scheme has the following advantages:

• 1) The domain name is incorporated, reducing the number of DNS calls and reducing the risk of DNS hijacking;
• 2) Keep-alive can be used to duplicate Http connections for the same domain name.
• 3) The client business layer does not need to change the code, and the back-end business services do not need to make any changes.

7. Short-link optimization Scheme 2: DIRECT IP connection

As a result of the domain name consolidation scheme, we have consolidated all the domain names into “api.dianping.com”. For this unique domain name, we can set up our own DNS service on the client side.

The solution is simple:

• 1) Pull all IP lists corresponding to “api.dianping.com” when the program starts;
• 2) Run a horse race test on all IP addresses to find the fastest IP address (all subsequent HTTPS requests should be replaced with the fastest IP address).

For example, suppose that the fastest IP corresponding to the domain name “api.dianping.com” is “1.23.456.789”.

Api.dianping.com/ad/command?param1=123 URL “http://” will be replaced by “http:// 1.23.456.789 / AD/command? Param1 = 123”

The direct IP connection scheme has the following advantages:

• 1) Abandoned the system DNS, reduce external interference, get rid of DNS hijacking trouble;
• 2) Self-built DNS update timing can be controlled;
• 3) Easy to change the IP list.

In addition, if your App domain name has not been merged, it is recommended to try using HttpDNS solution.

You can refer to the following articles:

Comprehensive Understanding of mobile DNS Domain name Hijacking and other miscellaneous diseases: Technical principles, Root causes, Solutions, etc.

Mobile DNS Optimization practice of Meitu App: HTTPS Request Time Reduced by Nearly half

Baidu APP Mobile Terminal Network In-depth Optimization Practice Sharing (I) : DNS Optimization

Iqiyi Mobile Terminal Network Optimization Practice sharing: Network Request Success Rate Optimization

Note the following when using the DIRECT IP connection method to process the HTTPS certificate: HTTPS requires the certificate to be bound to the domain name. In this case, you need to modify the HTTPS domain name verification on the client. For details, see three Methods of USING HTTPS Trust Certificates.

After domain name merger and IP direct connection scheme transformation, the end-to-end success rate of HTTP short connection has been improved from 95% to 97.5%, and the network latency has been reduced from 1500 milliseconds to 1000 milliseconds, which is a small investment with big output.

8, to further improve the end-to-end success rate: the construction of long connection channel

Next, to further improve the end-to-end success rate, it is necessary to start the construction of long connected channels.

HTTP / 8.1 2 technology

HTTP/2 (from HTTP/0.9 to HTTP/2: The History of HTTP/2) is the first technology that comes to mind — it has many advantages such as asynchronous connection multiplexing, header compression, request-response pipelining, and so on.

If you look at the HTTP/2 topology, it’s pretty simple:

HTTP/2 establishes a long connection channel between the client and server, and puts all requests of the same domain name on the long connection channel.

This topology has the following disadvantages:

• 1) Requests based on DNS will still face DNS hijacking risk;
• 2) Multiple connections are required for requests from different domain names;
• 3) It is difficult to optimize the network channel: the client and server are connected to a public network. If the server is deployed in multiple places, the cost will be high.
• 4) Difficult business transformation: HTTP/2 deployment requires business server transformation, and the more business servers are used, the greater the cost of transformation;
• 5) The degree of network protocol customization is small.

8.2 Agent long link mode

In contrast to HTTP/2, we recommend another proxy long connection pattern.

The topology of this pattern is as follows:

The basic idea is as follows:

• 1) Set up a proxy long link server between the client and the business server;
• 2) The client establishes a TCP long connection channel with the proxy server.
• 3) HTTP requests of the client are converted into binary packets on the TCP channel.
• 4) The proxy server is responsible for making HTTP requests with the business server, and the result of the request is sent back to the client through the long-connected channel.

The proxy long connection mode has the following advantages over HTTP/2:

1) No dependency on DNS:

The long connection channel between the client and proxy server is established through IP and has nothing to do with DNS. HTTP requests from clients are converted into binary data streams sent to the proxy server, and DNS resolution is not required. The proxy server forwards requests to the service server on the same Intranet. Therefore, the proxy server can set up its own DNS service to reduce the dependence on the public NETWORK DNS service. In this sense, proxy long connection mode is inherently capable of preventing DNS hijacking.

2) Requests from different domain names can reuse the same long-connected channel;

3) Easy channel optimization:

Compared with the deployment of the service server, the cost of deploying the proxy long connection server is much smaller, and the proxy long connection server can be deployed in many places in the country or even the world. When selecting a proxy long connection server, the client can find the fastest server IP address for connection. On the other hand, the network channel between proxy server and service server can also be optimized. The service quality of the channel can be greatly improved by setting up dedicated lines or renting Tencent cloud.

4) Be completely transparent to the business:

The business code of the client only needs to access the SDK of the network layer, regardless of whether the network request uses the long or short connection channel. The proxy server sends the request from the client to the service server in HTTP short connection mode. The service server does not need any modification.

5) Network protocol is fully customized.

8.3 Process of self-established agent long Connection Mode

The construction of self-built long link can be divided into the following cycles.

As the primary stage of development, the task of this period is mainly to set up the proxy relay server, and set up the complete link structure.

In order to protect the data security on the TCP channel, the binary communication data between the client and the proxy server can be encrypted to ensure the data security.

Establish a special line between the agent long connection server and the background service server. Dedicated lines can greatly reduce interference on the public network and ensure service stability.

Because the client requests are made over the TCP channel, when the proxy long connection server needs to be upgraded or fails due to extreme cases, the entire network service of the client will be unavailable.

To solve this problem, we prepared a Failover degradation solution — when the TCP channel cannot be established or fails, UDP can be used to provide another request channel for connectionless features. Alternatively, the proxy sends HTTP public network requests to the service server, bypassing the long-connection server (the actual effect of the Failover mechanism will be shown in the following sections).

Deploy agent long access points at multiple locations across the country. When a client establishes a long connection channel with the access point, the client can select the fastest server to access the access point, greatly reducing the channel connection speed and improving the communication quality. In the network optimization practice of the past two years, we have organized the network channel service of the client into an independent SDK, which includes self-built long-link communication service.

The complete network channel topology is as follows:

The network channel SDK in the figure contains three communication channels:

1) CIP channel:

CIP channel is the self-built agent long link channel mentioned above. CIP is the abbreviation of China Internet Plus, which is the registered English name of Meituan Dianping Group. The vast majority of requests in App communicate with CIP Connection Server through TCP sub-channel in CIP channel, and the CIP Connection Server forwards the received requests to API Server. Since the TCP subchannel may not work in some extreme cases, we deploy UDP subchannel and HTTP subchannel in the CIP channel, in which the HTTP subchannel bypasses the long-connected server and the service server to make direct requests through the public network. The average end-to-end success rate of CIP channels has reached 99.7%, and the average time is about 350 milliseconds.

2) WNS channel:

For disaster recovery, Tencent’s WNS is still included in the network channel SDK. In extreme cases where CIP channels are unavailable, WNS channels can also be used as a backup long-connection alternative.

3) HTTP channel:

The HTTP channel directly requests the API Server on the public network. Considering the importance of the long connection channel, requests for uploading and downloading large data packets may lead to congestion of the long connection channel if they are placed on the long connection channel. Therefore, we put CDN access, file uploading and frequent log reporting on the public network to make requests using HTTP short connection, and at the same time reduce the burden of the proxy long connection server.

Push solution: In the upper right corner of the network channel topology, there is a Push Server. It takes into account the duplex nature of the TCP channel and provides push capabilities for the network channel SDK. Notification push allows clients to be notified of changes in server data. Push schemes can replace time-consuming and inefficient polling schemes that are common in code.

9. Practical case demonstration

The following figure shows the end-to-end success rate comparison of a boot interface after long connection:

In the figure above, the black curve is the success rate curve of a startup interface in the short-connected channel. The average success rate is only 81%, especially severe jitter, indicating that the network service stability is not enough. The blue curve is the success rate curve of the same interface in the long-connected channel. The average success rate has reached 99% and the jitter has been greatly reduced.

Successful delay comparison diagram:

The figure above shows the successful delay curve in the same case. The blue line is the long connection delay curve, and the black line is the short connection delay curve.

Next, let’s look at the effect of Failover. The following figure shows a long connection server failure in 2015.

At that time, the Android client uses a Failover solution to Failover the short link or UDP channel when the long connection fails. Compared with iOS clients without Failover, the Failover mechanism has great advantages in maintaining the overall availability of the network.

10. Network configuration system display

Network channel SDK contains the CIP | being | HTTP three thoroughfare, channels have their merits and demerits of different control each request to choose the appropriate network channel became imminent important topic.

Therefore, we have developed a network configuration system, which can dynamically switch network channels for different API requests by issuing instructions to adjust the channel selection strategy in the NETWORK channel SDK in App.

The following figure is a schematic diagram of online channel switching of an interface:

The preceding figure shows the WNS channel switching process on an interface. The black line in the figure represents the request quantity curve under the short connected channel, and the blue line represents the request quantity curve under the WNS channel. After the channel switching command is delivered through the online control system, most of the short connection requests are switched to WNS channel requests within 5 minutes.

11. In the process of optimizing development, we found the rule

In the process of mobile network optimization development, we found the following rules.

The earlier the long link is established, the more requests can be made on the long link. Especially when the App is just opened, a large number of requests need to be made at the same time.

In this case, the strategy we adopt is to establish the long connection channel first, put many requests into the waiting queue, and then put the requests in the waiting queue on the long connection channel to send out successively after the long connection channel is established.

Using this strategy, we found an average 1.4% improvement in interface success and an average 160 ms reduction in latency at startup.

If the long connection channel does not use data slicing technology similar to HTTP/2, large packets can easily cause the long connection channel blockage.

When a fault occurs after a new function is online, you can degrade the fault by switching or parameter control or using ABTest to prevent the fault from spreading.

For example, the system network library handles network redirection internally, or the system network library automatically fills in default values if the request header does not contain accept-Encoding or Content-Type fields.

The keys in HTTP request header key-value pairs are allowed to be identical and duplicate. For example, the “set-cookie” field shown below contains multiple groups of the same key names. Similarly, there is the “Cookie” field. In long connection communication, if the key-value pairs in the header are saved and transmitted in an unprocessed dictionary manner, data will be lost.

12. A little advice

For growing startups, we have the following suggestions for improving your network.

1) Close down the network base: As the company grows and the development team grows, it is inevitable that more and more network libraries will be introduced. With more network libraries, centralized management of network requests becomes very difficult. Our suggestion is to set up our own network layer between the network library and the business code, and all the business network requests are made through the network layer code. In this way, it will be easier to replace the underlying network library or optimize the network channel in the future.

2) Use network monitoring: introduce network monitoring mechanism to discover network problems. Here I recommend the open source Cat monitoring system developed by our company. The open source address of Cat is github.com/dianping/ca… .

3) Try short connection optimization: the domain name merger and IP direct connection schemes mentioned above are simple and effective means.

4) You can try HTTP/2 or Tencent WNS long connection service (note: Tencent Cloud WNS service has been stopped).

Appendix: More information on network programming basics

[1.1] Weak network of mobile terminal

Summary of Optimization Methods for Short Connections in Modern Mobile Networks: Request Speed, Weak Network Adaptation, and Security Guarantee

Talk about long connections in iOS

Mobile IM Developers must Read (1) : Easy to Understand the “weak” and “Slow” mobile Web

Mobile IM Developers must Read (ii) : Summary of the Most Complete Mobile Weak Network Optimization Methods ever

Comprehensive Understanding of mobile DNS Domain name Hijacking and other miscellaneous diseases: Technical principles, Root causes, Solutions, etc.

Mobile DNS Optimization practice of Meitu App: HTTPS Request Time Reduced by Nearly half

Baidu APP Mobile Terminal Network In-depth Optimization Practice Sharing (I) : DNS Optimization

Baidu APP Mobile Terminal Network In-depth Optimization Practice Sharing (II) : Network Connection Optimization chapter

Baidu APP Mobile Terminal Network In-depth Optimization Practice Sharing (III) : Mobile Terminal Weak Network Optimization Chapter

Iqiyi Mobile Terminal Network Optimization Practice sharing: Network Request Success Rate Optimization

Mobile Terminal Network Optimization Practice of Meituan-Dianping: Greatly Improving connection Success rate and Speed, etc.

“5G era has arrived, TCP/IP old, still can eat?”

Wechat Mars: A Network Layer encapsulation library being used inside wechat, to be Open Source

As promised: Mars, a cross-platform component library of mobile IM Network layer for wechat’s own use, has officially opened source

Optimizing login Requests for Mobile IM Development

“Tencent original Sharing (I) : How to greatly improve the mobile QQ picture Transmission speed and success rate under the Mobile Network”

“Tencent Original Sharing (II) : How to greatly reduce APP Traffic Consumption in mobile Network (Part II)”

Tencent original Sharing (iii) : How to greatly reduce APP traffic Consumption under mobile Network (Part I)

Introduction to Zero-Base Communication technology for IM Developers (11) : Why WiFi Signal is Bad?

Introduction to Basic Communication technology for IM Developers (12) : Access to network traffic? Network Down? Get it!

Introduction to Zero-Base Communication technology for IM Developers (13) : Why Cell phone Signal is Bad?

How hard is wireless Internet access on high-speed Trains?

>> More similar articles……

[1.2] Network Programming Basics:

TCP/IP detail – Chapter 11 UDP: User Datagram Protocol

Chapter 17: TCP: Transmission Control Protocol

Chapter 18: Establishment and Termination of TCP Connections

TCP/IP Detail – Chapter 21: TCP Timeouts and Retransmission

Once upon a Time: The TCP/IP Protocol that Changed the World

“Understanding TCP in Depth (PART 1) : Fundamentals”

In – Depth understanding of TCP protocol (part 2) : RTT, sliding Windows, congestion Handling

Classic Theory: TCP three-way handshake and Four-way Wave

Wireshark Packet Capture Analyzing TCP Three-Way Handshake and Four-Way Wave

Computer Network Communication Protocol Diagram (Chinese Collector edition)

What is the maximum size of a packet in UDP?

P2P technical details (A) : NAT details – detailed principle, P2P introduction

Peer-to-peer (P2P) NAT traversal (hole) solution (Basic Principles)

Peer-to-peer NAT traversal (hole) solution (advanced analysis)

P2P technology details (4) : P2P technology STUN, TURN, ICE details

Easy to Understand: A Quick understanding of NAT Penetration in P2P Technology

“High Performance Network Programming (1) : How many Concurrent TCP connections can a Single server Have?”

“High Performance Network Programming part II: The Famous C10K Concurrent Connection Problem in the Last Decade”

High Performance Network Programming (PART 3) : The Next 10 Years, It’s Time to Consider C10M Concurrency

“High Performance Network Programming (IV) : Theoretical Exploration of High Performance Network Applications from C10K to C10M”

High Performance Network Programming part 5: Understanding the I/O Model in High Performance Network Programming

High Performance Network Programming (6) : Understanding the Threading Model in High Performance Network Programming

Java BIO and NIO are difficult to understand?

“Unknown Network Programming (1) : A Simple Analysis of the DIFFICULT Problems in TCP Protocol (part 1)”

“Unknown Network Programming (II) : A Brief Analysis of the DIFFICULT Problems in TCP Protocol (Part II)”

TIME_WAIT and CLOSE_WAIT when closing TCP connections

“Network Programming under the radar (Part 4) : A Deep Dive into TCP’s Abnormal Shutdown.”

Hidden Network Programming part 5: UDP Connectivity and Load Balancing

Unknown Network Programming (6) : Understanding UDP in Depth and Using it Well

Unknown Network Programming (7) : How to Make unreliable UDP Reliable?

Network Programming under the Radar (Part 8) : Deep Decryption of HTTP from the Data Transport Layer

Unknown Network Programming (9) : Connecting Theory with Practice, Understanding DNS in all Directions

Network Programming Lazy Introduction part 1: Quick Understanding of Network Communication Protocols part 1

“Network Programming Lazy Introduction ii: A Quick Understanding of Network Communication Protocols (Part II)”

“Network programming lazy Introduction (3) : A quick understanding of TCP protocol is enough.”

Network Programming Slacker’s Guide (part 4) : Quickly Understand the Difference between TCP and UDP

A Quick Look at why UDP Sometimes Has an Advantage over TCP

“Network programming lazy introduction (six) : The history of the most popular hub, switch, Router function principle introduction”

Web Programming Slacker’s Guide (7) : Understand HTTP in a Nutshell

“Network programming lazy introduction (8) : How to write tcp-based Socket long connection”

Web Programming for lazy People (9) : Why use MAC Addresses when you have IP Addresses?

Web Programming For lazy People (10) : Quick Reading of the QUIC Protocol in the Time it takes to pee

Internet Programming Slacker’s Guide (11) : Understanding IPv6

Technology Literacy: A New Generation of UdP-based Low Latency Network Transport Layer Protocol — QUIC In Detail

Making the Internet Faster: Sharing the technology practice of the new generation OF QUIC protocol in Tencent

Talk about long connections in iOS

Detailed explanation of IPv6 Technology: Basic Concepts, Application Status, Technical Practice (Part I)

Detailed explanation of IPv6 Technology: Basic Concepts, Application Status, Technical Practice (Part 2)

From HTTP/0.9 to HTTP/2: Understanding the History and Design of the HTTP Protocol

Learn TCP three handshakes and four waves with Animation

Introduction to Brain-dead Network Programming (II) : What are We Reading and writing when We read and write sockets?

Introduction to Brain-dead Network Programming (3) : Some must-know HTTP protocols

Introduction to Web Programming (4) : A Quick Understanding of HTTP/2 Server Push

Introduction to Brain-dead Network Programming (5) : The Ping command you Use every Day, What is it?

Introduction to Network Programming (6) : What is public IP and internal IP? What is NAT?

Introduction to Brain-dead Network Programming (7) : Essential face To face, The most popular Computer Network layering in history

Introduction to Brain-dead Network Programming: Do you really know the difference between 127.0.0.1 and 0.0.0.0?

Understanding the Technical Challenges of Real-time Communication by Taking The Network Access Layer Design of Online Game Server as an Example

Going High: The Basics of networking that Good Android Programmers Must Know and Know

Comprehensive Understanding of mobile DNS Domain name Hijacking and other miscellaneous diseases: Technical principles, Root causes, Solutions, etc.

Mobile DNS Optimization practice of Meitu App: HTTPS Request Time Reduced by Nearly half

UDP and TCP: An Android Programmer’s Must-know Network Communication Transport Layer Protocol

Introduction to Zero-Base Communication Technology for IM Developers (PART 1) : 100 Years of Communication Switching Technology (Part 1)

Introduction to Zero-Base Communication Technology for IM Developers (PART 2) : 100 Years of Communication Switching Technology (Part 2)

Introduction to Zero-Base Communication Technology for IM Developers (III) : The Century-old Change of Chinese Communication Mode

Introduction to Zero-Base Communication technology for IM Developers (iv) : Evolution of The Mobile Phone, The Most Comprehensive History of Mobile Terminals in History

Introduction to Zero-Base Communication Technology for IM Developers (5) : 1G to 5G, 30 Years of Mobile Communication Technology Evolution

Introduction to Zero-Base Communication Technology for IM Developers (6) : Contact Person of Mobile Terminal — “Base Station” Technology

Introduction to Zero-Base Communication Technology for IM Developers (7) : The Swift Horse of Mobile Terminal — “Electromagnetic Wave”

Introduction to Zero-Based Communication Technology for IM Developers (8) : Zero-Based, The Most Powerful “Antenna” Theory Literacy

Introduction to Zero-Base Communication Technology for IM Developers (9) : The Core Network — the Backbone of Wireless Communication Networks

Introduction to Zero-Base Communication Technology for IM Developers (10) : Zero-Base, Greatest 5G Literacy

Introduction to Zero-Base Communication technology for IM Developers (11) : Why WiFi Signal is Bad?

Introduction to Basic Communication technology for IM Developers (12) : Access to network traffic? Network Down? Get it!

Introduction to Zero-Base Communication technology for IM Developers (13) : Why Cell phone Signal is Bad?

How hard is wireless Internet access on high-speed Trains?

Introduction to Zero-Base Communication technology for IM Developers (Part 15) : Understanding Location Technology in one article

Sharing by Chen Shuo: From simple to deep, A Summary of Learning Experience of Network Programming

How Many HTTP Requests can You Make over a TCP connection?

Zhihu Technology Sharing: The Practice of High Performance Long Connection Gateway technology for Ten Million Level Concurrent In Zhihu

“5G era has arrived, TCP/IP old, still can eat?”

>> More similar articles……

(This article has been simultaneously published at: www.52im.net/thread-3015…)