XMPP连接时间优化

Question

我们正在基于XMPP Robbie Hanson框架编写iOS聊天应用程序.服务器端我们使用hazelcast插件在3台服务器上运行openfire.现在我们遇到了以下问题:客户端连接和身份验证大约需要2秒.没有TLS/SSL.使用TLS/SSL大约需要4秒.我们尝试了所有内容以缩短这个时间,因为如果用户收到推送通知他收到消息,打开应用程序并且实际获取消息需要很长时间,这看起来很奇怪.我们不使用SRV记录,因此它不能是花费那么长时间的DNS查找.我们尝试修改xmpp握手,以便用户从一开始就发送所有数据(startls,auth方法......),而不等待服务器响应,但服务器不接受此操作.我们还尝试使用速度更快的网络带宽服务器,但这没有帮助.最后我们甚至尝试使用ejabberd,但我们的时间完全相同,所以我们坚持使用openfire.

我们认为必须缩短连接时间的原因是像WhatsApp或Threema这样需要不到1秒的其他信使.那么你有什么建议吗,我们还能尝试什么？是否有可能只通过优化客户端而不修改openfire代码来达到那个时间？

非常感谢!

这是我的握手日志:

C2S - RECV (1083417823): <?xml version='1.0'?>
C2S - RECV (1083417823): <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' to='chat.example.com'>
C2S - SENT (1083417823): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="chat.example.com" id="5a051bc8" xml:lang="en" version="1.0">
C2S - SENT (1083417823): <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism></mechanisms></stream:features>
C2S - RECV (1083417823): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Starting Hazelcast Clustering Plugin
C2S - RECV (1083417823): <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' to='chat.example.com'>
C2S - SENT (1083417823): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="chat.example.com" id="5a051bc8" xml:lang="en" version="1.0"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism></mechanisms><auth xmlns="http://jabber.org/features/iq-auth"/></stream:features>
C2S - RECV (1083417823): <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="DIGEST-MD5"/>
C2S - SENT (1083417823): <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cmVhbG09Im5vZGVzLmZsaXhtaW5kZXIuY29tIixub25jer0iQ1hOS3MxWG9WY0xMTmsvedRUWlFIYmpGS1Vta2s4SG5WQ01TWUJnWiIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==</challenge>
C2S - RECV (1083417823): <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dXNlcm5hbWU9IjAwNDkyMjIiLHJlYWxtPSJub2Rlcy5mbGl4bWluZGVyLmNvbSIsbm9uY2UtrkNYTktzMVhvVmNMTE5rL3dEVFpRSGJqRktVbWtrOEhuVkNNU1lCZ1oiLGNub25jZT0iMkU2RURCRTctNUI2NC00QjQwLTg0OUMtQkUzQ0YwMTRCNTk0IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL25vZGVzLmZsaXhtaW5kZXIuY29tIixyZXNwb25zZT1mMDRhYzM4MjBlY2MwMGE1Mjk1ZTkxMjc5YTc1Zmz4MCxjaGFyc2V0PXV0Zi04</response>
C2S - SENT (1083417823): <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cnNwYXV0aD05NDk2NTA2NWRlNDQ2MzRhNWRlMWNzuTc0NjI3MGNhZg==</success>
C2S - RECV (1083417823): <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' to='chat.example.com'>
C2S - SENT (1083417823): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="chat.example.com" id="5a051bc8" xml:lang="en" version="1.0"><stream:features><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features>
C2S - RECV (1083417823): <iq type="set" id="F3CFA293-6D45-4E03-9065-3FD10D617C02"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/></iq>
C2S - SENT (1083417823): <iq type="result" id="F3CFA293-6D45-4E03-9065-3FD10D617C02" to="chat.example.com/5a051bc8"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>222@chat.example.com/5a051bc8</jid></bind></iq>
C2S - RECV (1083417823): <iq type="set" id="D351FF85-535B-4B08-B5C2-3C11D92C1EA9"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq>
C2S - SENT (1083417823): <iq type="result" id="D351FF85-535B-4B08-B5C2-3C11D92C1EA9" to="222@chat.example.com/5a051bc8"/>
C2S - RECV (1083417823): <presence/>
C2S - SENT (1083417823): <presence from="222@chat.example.com/5a051bc8" to="222@chat.example.com/5a051bc8"/>
C2S - SENT (1083417823): <presence from="222@chat.example.com/5a051bc8" to="222@chat.example.com/5a051bc8"/>
CLOSED (1446853640) 

Answer 1

我建议尝试获取一些日志,以确切了解花费最多时间的内容.确切地确定您正在使用的往返次数将帮助您确定要优化的内容.

有一个XEP用于XMPP快速入门,XEP-0305.这有一些一般的建议,但也有一个流水线协议,如果您的服务器和客户端支持,它应该为您捆绑数据.

一些技巧:

• 确保缓存指定TTL的DNS结果.
• 在本地保存用户的名单并使用名册版本控制只能获得可能发生在用户名单上的任何更改.
• 在TLS级别,您可以尝试恢复会话或错误开始工作.还要确保服务器不发送额外的证书(比如您知道客户端会信任的根).使用更快的算法(ECDHE代替DHE,RSA-2048而不是RSA-4096),但要记住安全(请不要RC4).
• 如果您执行设置/检索vCard,服务发现等操作,请确保以后发生并且不会阻止任何其他操作.
• 如果您使用的是SCRAM-SHA-1且服务器使用散列密码存储(即每次都发送相同的盐),您可以缓存该SaltedPassword值,这应该可以节省大量时间.
• 如果您的服务器足够新(因此正确实现RFC 6121),您可以跳过urn:ietf:params:xml:ns:xmpp-sessionIQ 跳过往返.请参阅https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/?include_text=1.
• 缓存联系人和服务器的实体上限以跳过检索它们.您甚至可以在应用内嵌入经常使用的大写字母.
• 如果您想在任何步骤同时发送多个节,请确保它们是在单个TLS数据包中发送的.每个数据包都有一个开销大小(介于25-85个额外字节之间:标头,IV,填充,MAC)和处理时间(解析,验证MAC).