Analysis on the optimization of login request in IM development of instant messaging mobile terminal

What is the “ land ” still “ Sign in ”？ This is a problem that many virgin developers struggle with , However, it is not the content of this text . This article will focus on the mobile terminal IM The login function of gives corresponding optimization suggestions .

Origin

In mobile IM Module , The core and most complex module is the login module . A login module that has not been well optimized often takes a long time and wastes traffic ： A single login can take tens of seconds , For a few minutes , Synchronize hundreds of at the same time KB Even a few M The data of .

A simple login step can be divided into the following steps ：

    1） request lbs;
    2） Connect link;
    3） Send and receive login requests ;
    4） Sync IM data .

And every step here has the possibility of optimization .( In fact, many of the following ideas are universal , It's not just IM APP To use ).

Optimize load balancing LBS request

stay PC Time , We will often ask lbs Make a series connection with the connection server , After all, we have to finish the request first lbs To get the real link Server address , So as to carry out the connection operation . In specific operation , commonly lbs A request is a request HTTP request , The time it takes here can be imagined . So a simple optimization idea is to remove this link from the login process .

However, direct rough removal lbs Requests are not desirable , If we directly built in the domain name or ip, The biggest problem is the inability to do load balancing . Therefore, it is more recommended to lbs Request asynchronization ： Don't do it when you log in lbs request , When the network is idle and changes, it makes requests and caches , Each time you log in, you get it directly from the local cache link Address .

DNS Optimize

Use TCP It is inevitable to encounter DNS The problem of resolution , After all, we can't always use IP As the server address . stay PC Time ,DNS Parsing is almost painless . But in the wireless age ,DNS Related problems are becoming more and more serious . One side , Under mobile network ,DNS The parsing speed is incomparable , once DNS The parsing time can even catch up once TCP Connection time , Seconds , Ten seconds , Even three , Forty second request times are common . On the other hand , Due to the operator's inaction and act , Under the mobile network DNS It also shows that the resolution accuracy is low and it is often hijacked .

In these cases, consider using HTTP DNS,github There are also many open source implementations , such as HttpDNSLib. The most radical method is to optimize as before lbs equally , Avoid in each link DNS analysis .

    1）lbs Back to the server ip Not a domain name
    2） Local cache lbs ip Address standby , request lbs Priority is given to the use of ip Not a domain name

This way can not only avoid DNS The time taken to request , It can also be avoided to some extent DNS The question of being hijacked . The drawback is that in this case, a series of other problems need to be considered on the client side ： How to go from ip list Select a valid address , Determine when to re request , Load balancing , Saving traffic, etc .

Login authentication request optimization

in fact , There is not much room for optimization in the login authentication request process . Once you connect to the server , The next thing to do is to encrypt the current connection and send and receive login feedback . These two steps are indispensable . Instant messaging chat software app Development can add Weike cloud consulting

And how to optimize is often related to the specific business ： Suppose we use something like HTTPS General three-step negotiation encryption process , Security can indeed be guaranteed , But there are too many times , The whole login time will increase . The trick is naturally to combine encryption and login requests , This often involves the modification of login requests .

Data synchronization strategy optimization

After login , The client needs to synchronize from the server , A regular IM APP The following data needs to be synchronized ：

    1） The friends list ;
    2） Friends' personal information ;
    3） Group list ;
    4） List of group members ;
    5） Group member personal information ;
    6） offline message .

Suppose a user has 1000 A good friend , 20 individual 50 The crowd , On average, each item is about 200 Bytes , Then a full synchronization will take about 0.2 * (1000 + 1000 + 20 + 1000 * 2) = 800 KB The data of , This is for a mobile IM It's unacceptable , What's more, this is the data volume of a relatively mild user .

Obviously full synchronization is not acceptable , The improved method is to synchronize by timestamp . The client will always only update data that is newer than the locally cached data . This is a general optimization direction .

There are also some optimizations that can be implemented according to business needs ： Deferred and on-demand updates . Take the personal information of group members as an example , In fact, users don't care about real-time , After all, these group members are not necessarily friends of users , Their information changes can be completely updated when users view it （ Wechat strategy ）. The same is true of friends' personal information , For most interfaces , They only care about users Id, Avatar and nickname are three basic information , And some icing on the cake Profile The information can be updated by time stamp when the user views the corresponding interface .