普通 xmpp 客户端和普通 xmpp 服务器之间的身份验证和资源绑定过程会经过大量的 xmpp 消息。服务器和客户端之间有很多 xmpp 消息来往。这种情况会按预期增加登录持续时间。
我们将深入研究身份验证期间的消息传递顺序，并分析如果我们在身份验证之前已经知道一些预定义值，是否可以消除一些无关紧要的消息。
下图是客户端和服务端之间普通的认证和资源绑定消息时序图：
让我们深入研究这些消息：
1.流-ip
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
首先，客户端将流消息发送到服务器以启动 xmpp 流。这是打开客户端和服务器之间的流的第一条消息。
2. 流特征消息 - 1
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
打开流后，服务器通过上面的消息将其初始功能返回给客户端。该消息表示服务器支持 tls、普通身份验证机制、身份验证以及非身份验证客户端的注册功能。
3.启动TLS
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
收到服务器特性后，客户端与服务器协商安全传输。
4.继续tls
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
服务器将 tls 继续消息返回给客户端，其中包括客户端可以安全地继续流式传输。
5.流-服务器
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
在收到继续消息后，这次客户端启动与服务器的安全流。
6. 流功能消息 - 2
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
服务器在启动 tls 后再次将其功能返回给客户端。
7.授权
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
最后，客户端将其密码发送给服务器进行身份验证。
8.成功
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
如果密码正确，则服务器对客户端进行身份验证并将成功消息返回给客户端。
9.流服务器
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
收到成功的身份验证消息后，客户端需要经过身份验证的客户端的服务器功能。
10. 流特征消息 - 3
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
服务器通知客户端它可以绑定资源或启动会话。
11. 资源绑定
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
在收到经过身份验证的客户端的服务器功能后，资源将被客户端发送以进行绑定。
12.绑定成功
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
客户端从服务器接收绑定结果消息。
13.会话开始
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
在序列结束时，客户端将会话开始消息发送到服务器并且流式传输开始:)
如果我们在身份验证之前知道一些预定义的配置，现在我们可以检查可以消除哪些消息。
A。开始
如果我们知道我们将始终在客户端和服务器之间启动 tls，那么第 3 条和第 4 条消息就变得无关紧要了。服务器和客户端自动启动 tls，因为他们已经知道了。
b.流功能消息 - 2
在客户端，假设我们最初知道服务器支持身份验证、注册和普通身份验证机制。然后不需要从客户端向服务器发送第 5 条消息。第 5 条和第 6 条消息被删除。
C。流功能消息 - 3
我们还假设客户端知道经过身份验证的客户端的服务器功能，在我们的例子中是绑定和会话，那么就不需要向服务器询问这些功能。
如果在客户端和服务器之间引入了一种新的消息类型，其中包括身份验证纯文本和要绑定的资源，则服务器可以同时处理这两个过程。这个带有新命名空间的新消息将由服务器处理，可以引入为：
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
如所见，该消息包括密码和资源。如果认证绑定成功，那么服务端可以返回绑定结果iq给客户端：
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
在返回时，它知道会话消息将由客户端发送，然后它可能会在没有收到来自客户端的会话消息的情况下采取会话操作，然后客户端会话消息也被消除。
如果我们总结新的消息传递顺序：
1.流
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
2. 流特征消息 - 1
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
3.授权与绑定
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
4.绑定成功
<stream:stream to="0.0.0.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" version="1.0">
新的认证和资源绑定过程的时序图如下所示：
如上所示，如果我们一开始就知道服务器作为客户端的功能，那么只有 4 条消息就足以成功进行身份验证。这个新序列如预期的那样显着减少了登录持续时间。 xmpp 服务器唯一要引入的是处理新的身份验证和绑定消息。