使命必达: 深入剖析WCF的可靠会话[原理揭秘篇](下)

上面一部分我们站在信道层的角度剖析了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)是由两个简单消息交换模式(单向或者请求|回复模式)组合而成,具体消息交换方式你应该可以上面接受推导出来,在这里就不再赘言讲述了。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏前端儿

XSS 和 CSRF 攻击

web安全中有很多种攻击手段,除了SQL注入外,比较常见的还有 XSS 和 CSRF等

2311
来自专栏Hongten

HTTP协议

众所周知,Internet的基本协议是TCP/IP协议,目前广泛采用的FTP、Archie Gopher等是建立在TCP/IP协议之上的应用层协议,不同的协议对...

1352
来自专栏月牙寂

k8s源码分析-----kubelet(7)containerRuntime

第一时间获取文章,可以关注本人公众号 月牙寂道长 yueyajidaozhang

4606
来自专栏虚拟化云计算

一文看懂ovirt的supervdsmd服务

在ovirt的计算节点上supervdsmd.service是有root用户权限的,可以操作系统底层的资源,其他的服务需要与之通讯来完成对资源的操作。

3316
来自专栏彭湖湾的编程世界

【webpack】流行的前端模块化工具webpack初探

有一天我突然意识到一个问题,在使用react框架搭建应用时,我使用到了sass/less,JSX模版以及ES6的语法在编辑器下进行开发,使用这些写法是可以提高开...

1234
来自专栏北京马哥教育

Linux DNS 服务器安装、配置和维护

每个 IP 地址都可以有一个主机名,主机名由一个或多个字符串组成,字符串之间用小数点隔开。有了主机名,就不要死记硬背每台 IP 设备的 IP 地址,只要记住相...

4935
来自专栏分布式系统进阶

Kafka的消息是如何被消费的?Kafka源码分析-汇总

1873
来自专栏IT技术精选文摘

从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

HTTP 协议是互联网的基础协议,也是网页开发的必备知识,最新版本 HTTP/2 更是让它成为技术热点。

1194
来自专栏同步博客

HTTP协议详解以及URL具体访问过程

  即超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准...

6954
来自专栏彭湖湾的编程世界

【webpack】流行的前端模块化工具webpack初探

从开发文件到生产文件 有一天我突然意识到一个问题,在使用react框架搭建应用时,我使用到了sass/less,JSX模版以及ES6的语法在编辑器下进行开发,使...

2586

扫码关注云+社区

领取腾讯云代金券