窄带网络环境下即时通讯系统(IM)登录优化

最近在处理IM在窄带网络环境下不能使用的问题，现该问题已经解决，将其总结一下，供需要的人参考。

1、问题背景

顾客反映IM在窄带网络环境下不能工作，具体表现为IM登录不上，系统无法工作。

2、解决问题过程

1、  先收集故障现场的网络参数，经过测试分析发现出现故障的网络环境如下：

网络带宽：256KBPS~2048KBPS

丢包率：0~10%

延时：30ms ~6s(ping)  

抖动：0~1s

2、  通过网络模拟软件（Shunra.VE.SMB.Editon）构建网络环境，测试分析IM不能登录的真正原因。

3、  将网络环境改为正常状况，待IM登录成功后，再将网络环境切换为窄带环境（带宽：512KBPS,延时：6s（ping）,抖动：1s，丢包率：10%），发现IM能正常发送短信，也能进行语音通话，只是延时较大，语音还算清晰。将该网络环境定为改进的目标环境。问题的关键是登录，语音和即时消息的UDP报文传输没有大问题。

4、  通过Wireshark分析登录过程报文，经多次试验发现以下问题：

a)         登录不上的原因主要有：http访问超时，sip报文访问超时，IM的联系人列表下载超时。

b)        IM在登录时会多次HTTP请求服务器，每次都会重新建立TCP连接，响应完毕后，断开连接，一次TCP连接建立的时间约6秒。

c)         联系人列表采用XML格式，联系人满配时，列表报文约300KB，在目标网络环境下，该联系人列表的下载时间约600秒。

5、  改进措施：

a)         IM发送HTTP请求时设为保持TCP连接，Web服务器设置保持TCP连接，保持超时设为120s，TCP连接通过Web服务器的超时断开，避免短时间内每次HTTP请求都重新建立TCP连接。

b)        联系人在客户端缓存，IM登录时服务器只下发差异部分。

c)         对联系人进行压缩，对于联系人较多的情况进行分包处理，分多次下载。

d)        IM提供手工下载联系人的方法，对于登录时下载不了联系人的情况，可以在登录后的某个时候手工下载。

e)         对UDP报文的长度进行检查，尽量控制在1000字节一下，确保不超过网络的MTU。

 

3、总结

1、  通过这个问题的处理发现，影响系统的关键不是带宽太小，而是延时和丢包，合理设置系统的延时非常重要。

2、  要多做实验，用事实说话，在本文提到的网络环境中，建个TCP连接要6秒，传一个300KB 的HTTP报文要600秒，这个数据刚开始感觉奇怪。实际上，报文大了，丢包增多了、报文延时，再加上TCP的拥塞控制，综合在一起考虑也正常。

3、  在恶劣的网络环境下，TCP连接的建立是非常耗时的，这个对于做Web应用系统的人最容易忽视。

4、  在恶劣的网络环境下，TCP的性能表现不如UDP，如：同一个网络环境中能打电话、聊天(基于UDP)，但是登录（基于TCP）却容易出问题。由于受教科书的影响，很多人都认为TCP可靠，UDP不可靠。实际上这是不对的，只不过TCP的可靠性是由协议栈提供，而UDP的可靠性需要由应用系统自己实现。TCP的连接建立以及拥塞控制机制使TCP协议的性能大打折扣，如采用UDP协议，则可靠性和拥塞控制完全由应用系统自身控制，而不受协议栈的影响。

5、  在恶劣的网络环境下，HTTP报文不能太大，遇到大报文的应用情况，应尽量想办法避免。举个例子，在不稳定的网络环境下网上邻居拷文件，考一个100MB的文件容易，还是考一个10MB的易呢？道理是一样的。

 

注：本文提到的网络环境主要是指一些非洲国家和受干扰较为严重的无线网络环境。