上面一部分我们站在信道层的角度剖析了WCF为了实现可靠会话在信道层进行的一系列消息交换，或者说客户端和服务端的RS信道为了实现可靠消息传输所进行一轮又一轮的握手。这一切都是基于这样一个假设：两个RS信道均可以在适当的时机向对方发送消息，或者说两个RS信道之间是一个双工的通道。
如果我们站在传输层看待这个问题，该假设对于TCP传输是成立的，但是对于HTTP来说就有点问题了。HTTP本身就是一个基于请求|回复消息交换模式的应用层网络协议，并不能对双工通信提供支持。而WCF通过WSDualHttpBinding实现的双工通信机制和NetTcpBinding支持的双工通信具有本质的区别。NetTcpBinding创建的传输通道就是一个双工的TCP连接，而WSDualHttpBinding创建的所谓的双工通道实际上是两个方向相反的HTTP连接。接下来我们主要讨论当我们采用基于HTTP绑定——WSHttpBinding（或者是WS2007HttpBinding）和WSDualHttpBinding）时，实现可靠会话所进行的通信方式。
一、WSHttpBinding V.S. WSDualHttpBinding
如果采用WSHttpBinding，最终创建的是一条从客户端到服务端的HTTP通道。在这种情况下，客户端RS信道和服务RS信道之间的多轮握手（CreateSequence/
CreateSequenceResponse、Sequence/
SequenceAcknowledgement、CloseSequence/CloseSequence和TerminateSequence/TerminateSequenceResponse）均是采用这样的消息交换方式：客户端将相应的消息通过HTTP请求的形式发送到服务端，相应的回复或者确认通过HTTP回复返回。图1揭示了上述的几次握手在传输层上的实现，其中实线部分代表HTTP请求，虚线部分代表HTTP回复。
图1 可靠会话基于通过WSHttpBinding创建的单通道的消息交换
从图1中我们可以和清晰地看到，CreateSequence/
CreateSequenceResponse、CloseSequence/CloseSequence和TerminateSequence/TerminateSequenceResponse完全是按照HTTP请求/HTTP回复的形式实现的。在进行服务调用的时候，即使采用的单向消息交换模式，发送应用消息的请求依然会接收到一个包含SOAP消息的HTTP回复。服务端通过将确认消息方法每一个HTTP回复之中。
之所以采用如上的方式的根本目的在于，WSHttpBinding创建的传输层通道是从客户端到服务端的一条HTTP连接。HTTP连接是一条单工通道，客户端和服务端总是扮演者请求者和回复者的角色，服务端不能主动联系客户端，此外无论是对RM序列创建、关闭和中指的回复，还是消息确认只能放在HTTP回复中。
但是，如果我们采用WSDualHttpBinding作为终结点绑定，情况就大不一样了。由于WSDualHttpBinding会创建两条HTTP连接构成一个所谓的双工通道，服务端可以随时联系到客户端，不需要将相应的回馈通过HTTP回复随带捎回去。借助于WSDualHttpBinding创建的双工通道，可靠会话的上述握手采用如下的消息交换方式：客户端通过HTTP请求将RM序列创建、终止请求以及携带Sequence报头的应用消息发送给服务端，并得到一个状态为202的空HTTP回复。而真正的回复和消息确认都通过另一个HTTP连接的HTTP请求返回给客户端的，而这些HTTP请求通过会得到一个状态为202的空HTTP回复。
图2是对可靠会话消息交换在传输层的反映。可能你会觉得这和我们上面介绍的WS-RM消息交换模式不一致，没有了CloseSequence/CloseSequence握手，对于TerminateSequence请求也没有相应的TerminateSequenceResponse回复，这是因为WSDualHttpBinding支持的WS-RM版本是1.0，而不是我们上面介绍的1.1。除了上述的两点不同之前，还有一个不一样的地方：客户端在发送RM序列终止请求之前会发送一个携带Sequence报头的空消息，而对于包含在该空消息中的Sequence报头，除了包含消息序号之外，还具有一个额外的LastMessage元素表明这是RM序列终止前的最后一个消息。关于WS-RM
1.0，限于篇幅的因素，在本书中不可能再进行深入的介绍，有兴趣的读者可以参阅OASIS官方文档。
图2 可靠会话基于通过WSDualHttpBinding创建的双通道的消息交换
我们也可以从另外一种视角来看WSHttpBinding和WSDualHttpBinding对可靠会话的不同实现方式。对于WSHttpBinding创建的单向信道来说，客户端对于服务端是一个不可寻址（Non-Addressable）的终结点。也就是说，客户端不能主动向客户端发起请求，只能在客户端对自己发起请求时，被动地将相应的信息通过HTTP回复的形式返回到客户端。但是，对于WSDualHttpBinding创建的双工信道，情况就不一样了。双工通道是客户端和服务端成为了对等终结点，无论是服务端还是客户端，对于对方来说都是可寻址的（Addressable）。服务端可以在任何时候向客户端发起请求，将相应的信息通过HTTP请求的方式发送给客户端。
双工通道成就了可靠会话的“批量确认”机制。为了尽可能地降低网络流量，接收端RS信道接收到消息之后，并不会立即为该消息进行单独确认，而是会等待一定的时间（通过ReliableSessionBindingElement的AcknowledgementInterval属性设置），对之前接收到的消息进行批量确认。由于接收端RS信道接收到消息和发送确认有一定的延迟，我们也称这种机制为“延迟确认”。
二、单向模式（One-Way）V.S.请求|回复（Request|Reply）和双工（Duplex）模式
决定实现WCF可靠会话真正采用的消息交换还具有另外一个因素：消息交换模式。单向模式和请求|回复以及双工模式下，可靠会话采用的消息交换方式具有很大的不同。如果终结点服务契约中的所有操作均是单向的（通过OperationContractAttribute特性的IsOneway属性设置），对于可靠会话来说仅仅存在一个从客户端到服务端的RM序列。反映在序列的创建上就意味着在客户端RS生成的CreateSequence消息中并不存在Offer结点。
从应用层次讲，单向操作意味着客户端向服务端发送消息而不会接收到任何回复。由于服务端不会有任何的应用消息从服务端返回到客户端，服务端的RS信道只能创建一个空的SequenceAcknowledgement消息对接收的消息进行确认。
如果终结点服务契约中的所有操作中具有一个以上的非单向操作，WCF可靠会话不仅仅需要保障消息从客户端到服务端的可靠性，也需要对服务端到客户端的消息传输提供保障，所以WCF可靠会话需要建立两个方向相反的RM序列。具体来说，可靠会话采用“序列提供”机制创建了双向的RM序列。在客户端RS信道生成CreateSequence之前现在本地创建一个RM序列，然后将该序列封装到CreateSequence消息的Offer元素中“提供”给服务端。服务端RS信道接收到CreateSequence消息之后，处理创建客户端请求的RM序列之外，还会接受（或者拒绝）提供的序列。
不同于单向模式下采用单独的SequenceAcknowledgement消息进行消息确认，在请求|回复模式下，为了尽量降低网络流量，可靠消息采用“背负（piggy-back）”机制实现消息确认。具体来说，客户端RS信道将SequenceAcknowledgement报头放到请求消息中，实现对接收到的回复消息的确认；服务端RS信道则将SequenceAcknowledgement报头放到回复消息中，实现对已经接收到的请求消息的确认。
而双工（Duplex）是由两个简单消息交换模式(单向或者请求|回复模式)组合而成，具体消息交换方式你应该可以上面接受推导出来，在这里就不再赘言讲述了。
作者：蒋金楠
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。