ssl - 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

我建议尝试获取一些日志，以准确地找出什么 花费了最多的时间。准确计算出您使用的往返次数将有助于您确定要优化的内容。

XMPP 快速入门的 XEP，XEP-0305 .这有一些一般性建议，还有一个流水线协议(protocol)，如果您的服务器和客户端支持，它应该为您捆绑数据。

一些提示:

• 确保为指定的 TTL 缓存 DNS 结果。
• 将用户名册保存在本地，并使用名册版本控制仅获取用户名册可能发生的任何更改。
• 在 TLS 级别，您可以尝试恢复 session 或错误地开始工作。还要确保服务器不发送额外的证书(比如你知道客户端会信任的根证书)。使用更快的算法(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 个额外字节之间: header 、IV、填充、MAC)和处理时间(解析、验证 MAC)。