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

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

XMPP快速入门有一个XEP，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-session IQ跳过往返。见https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/?include_text=1。
缓存联系人和服务器的entity caps以跳过检索它们。您甚至可以在应用内嵌入经常使用的大写字母。
如果您想在任何步骤同时发送多个节，请确保它们是在单个TLS数据包中发送的。每个数据包都有一个开销大小（介于25-85个额外字节之间：标头，IV，填充，MAC）和处理时间（解析，验证MAC）。

Answer 2

现在看来你现在还没有花4秒的时间，很难给你一个具体的答案。我喋喋不休地试着描述一下这个时间框架并确定调用了哪些机制/阶段/方法以及完成它们需要多长时间。

有XEP-305: XMPP Quickstart。这可能会为您提供更多信息。除此之外，我怀疑你可以在不修改服务器代码的情况下改善建立XMPP会话所需的时间。

Answer 3

作为一个数据点，我使用基于SleekXMPP客户端的移动客户端大规模部署ejabberd，并且连接延迟没有问题。我经常使用OpenFire进行小规模的办公通信，而且也不是那么慢。

移动网络很棘手。尝试从桌面XMPP客户端连接到您的服务器，最好是在与服务器相同的网络上。这将帮助您消除（或暗示）网络和移动客户端的问题。

如果问题与服务器隔离，唯一可能的情况是您已经过载。如果您只是连接一个客户端，那么您的服务器非常贫血，或者您正在与某些外部数据库进行通信以进行身份验证，并且该数据库过载。

如果问题不是服务器，请尝试将移动客户端连接到WiFi而不是单元网络。然后运行与客户端相邻的数据包嗅探器和服务器上的另一个数据包嗅探器。这应该告诉你是否有一些客户端错误或网络问题。

XMPP连接时间优化

3 个答案: