第2章地址Address(WCF全面解析3)

WCF顾明思义,就是在Windows平台下解决通信(C,Communication)的基础框架(F,Foundation)问题。 终结点是WCF最为核心的对象,因为它承载了所有通信功能。服务通过相应的终结点发布出来,客户端通过与之匹配的终结点对服务进行调用。终结点由代表地址、绑定和契约的ABC三要素构成。 作为终结点的三要素之一的地址(Address)、在基于WCF的通信中不仅仅用于定位服务,还提供额外的寻址信息。除此之外,终结点还和安全有关系,因为它包含着用于进行服务认证的服务身份信息。

目录

2.1 统一资源标识(URI) 2.1.1 HTTP/HTTPS 2.1.2 Net.TCP 2.1.3 Net.Pipe 2.1.4 Net.Msmq 2.2 EndpointAddress 2.2.1 服务端终结点地址 2.2.2 客户端终结点地址 2.2.3 地址报头 2.3 端口共享 2.3.1 端口共享意义何在 2.3.2 HTTP|HTTPS端口共享 2.3.3 TCP端口共享 2.4 逻辑地址与物理地址 2.4.1 服务的角色 2.4.2 监听地址与监听模式 2.4.3 ClientViaBehavior 2.4.4 实例演示:通过tcpTrace进行消息的路由(S205,S206) 2.5 请求监听与消息分发 2.5.1 连接请求的监听 2.5.2 消息分发

统一资源(URI)

URI全称是Uniform Resource Identifier(统一资源标识),它唯一地标识一个网络资源的同时也标识资源所处的位置及访问方式(资源访问所用的网络协议)。URI具有如下的结构:

传输协议://[主机名称|域名|IP地址]:[可选端口]/[资源路径]

2.1.1 HTTP/HTTPS

HTTP全称为HyperText Transfer Protocol(超文本传输协议),是建立在TCP/IP簇上的应用层协议。

HTTP提供简单的请求-恢复(Request-Reply)消息传输方式
HTTP是无态的,每次HTTP请求都是相互独立的
HTTP是无连接的,基于HTTP的数据传输无需事先打开连接

HTTPS全称为HyperText Transfer Protocol over Secure Socket Layer(安全超文本传输协议),它是采用了SSL(Secure Socket Layer)的HTTP,而SSL是一个进行数据加密的协议,很多安全性要求较高的网站都采用HTTPS。
WCF通过HTTPS实现了基于HTTP的传输安全(Transport Security)。

HTTP和HTTPS的URI分别使用http和https作为传输协议的前缀(Scheme),默认使用的端口分别为80和443,所以下面两组URI是等效的。

http://artech.com:80/myservices/calculatorservice.svc

https://artech.com:443/myservices/calculatorservice.svc

http://artech.com/myservices/calculatorservice.svc

https://artech.com/myservices/calculatorservice.svc

2.1.2 Net.TCP

TCP全称为Transport Control Protocol(传输控制协议),在整个TCP/IP簇中处于核心地位。从整个协议分层结构来看,位于应用层之下,网络层(IP协议)之上。较之HTTP,TCP有如下特定:

TCP是基于连接的传输协议,在开始进行数据传输之前,通过客户端和服务端之间的3次“握手”创建连接;在结束传输之后,通过4次“握手”终止连接。
TCP是有状态的,由于数据传输在一个确定的连接中进行,因此可以保持每次数据传输的状态。

TCP支持全双工(Duplex)通信,一旦连接成功创建,数据就可以在两个方向上同时传输。

TCP支持可靠通信(Reliable Messaging),IP协议本身提供的数据传输是不可靠的,数据的可靠传输只能通过TCP来保证。

WCF通过NetTcpBinding支持基于TCP的传输。对于TCP的URI,其传输协议前缀均为net.tcp://。Net.TCP默认的端口为808,下面两个URI完全是等效的。

net.tcp://artech.com:808/myservices/calculatorservice

net.tcp://artech.com/myservices/calculatorservice

2.1.3 Net.Pipe

命名管道(Named Pipes)是Windows平台及UNIX系统下实现跨进程通信(Inter Process Communication,IPC)的标准实现方式。虽然命名管道本身可以实现跨机器的通信,但是WCF只将命名管道专门用于同一台机器的跨进程通信,所以基于命名管道的URI的主机名称|IP地址部分只能是本机的机器名、localhost或127.0.0.1。下面是一个典型的Net.Pipe URI

net.pipe://127.0.0.1/myservices/CalculatorService

2.1.4 Net.Msmq

消息队列(Message Queuing,也称MSMQ),是微软对消息服务领域的开创性尝试。由于消息队列采用了特殊的通信机制,因此对于改善和提高系统的可扩展性(Scalability)和高可用性(High Availability)具有重要的意义。按照可访问性,消息队列可分为如下两种类型。

公共消息队列:共有队列的名称被注册到AD域中,所以我们无须指定队列所在的机器名称就可以访问队列。当将某个共有队列从一台机器转移到另一台机器时,访问该队列的应用可以保持不变。共有队列还可以提供基于域账号的Windows认证机制,所以对于正式发布的应用来说,通常采用共有队列。

私有消息队列:因为共有队列需要注册到AD域中,所以它只能用在域(Domain)模式下。在工作组(Work Group)模式下,只能使用私有队列。而访问私有队列需要制定包含队列所在机器名称的路径。

除了普通的用于存储业务数据消息的普通队列之外,还有存储确认消息的管理队列、存储消息拷贝的日志队列、存储回复消息的回复队列、存储死信消息的死信队列等。除了基于独立文件的物理队列之外,还有依附于物理队列的子队列。

WCF下基于消息队列的URI具有net.msmq前缀。在主机名和队列名称之间通过字符Private表示私有队列,而对于公有队列的URI,表示队列类型部分则不是必需的。下面给出了两个Net.Msmq地址。

net.msmq://artech.com/myservices(公有队列)

net.msmq://artech.com/private/myservices(私有队列)

2.2 EndPointAddress

终结点在WCF应用编程接口中通过System.ServiceModel.Description.ServiceEndpoint类型表示。三个核心属性分表表示终结点的地址、绑定和契约三要素.

2.2.1 服务端终结点地址

2.2.2 客户端终结点地址

2.2.3 地址包头

2.3 端口共享

对于一些常用的网络服务,它们都有一个知名端口号与之匹配:FTP服务的TCP端口为21,Telnet服务的TCP端口为23

而客户端通常对所使用的端口并不关心,只需要保证端口在本机是唯一的就可以了。这样的端口幼教临时端口,临时端口一般在1024~5000之间

2.3.1 端口共享意义何在

在一般的网络环境中,为了尽可能避免网络攻击,都会通过防火墙将绝大部分的端口进行屏蔽,仅仅保留哪些常用的网络服务所用的端口,或者仅为某一类应用保留少量的端口。总而言之,我们不能保证每个跨防火墙通信的应用都具有一个唯一的端口,它们只能共享一个活少量的几个端口。

在Intranet内部,为了保证部署与局域网内的其他计算机的网络应用能够与本级进行正常通信,通常会在本级的防火墙中预留少数几个可用的端口。intranet内部的主机之间可以使用这些预留的端口,通过相应的传输协议进行通信。而对于处于internet和本地网络之间的防火墙,通常只保留80|443端口,保证基于HTTP|HTTPS的网络通信能够正常进行。所以无论基于Intranet还是Internet,端口共享都具有现实意义。

2.3.2 HTTP|HTTPS端口共享

2.3.3 TCP端口共享

Net.TCP端口共享服务

从功能上讲,Net.TCP端口共享服务实现了HTTP.SYS相同的功能,即请求的监听和分发。不过HTTP.SYS运行在内核模式(Kernel Mode)下,而Net.Tcp端口共享服务运行在用户模式(User Mode)下

TCP端口共享与NetTcpBinding

在netTcpBinding节点下的binding中配置portSharingEnabled=“true”

2.4 逻辑地址与物理地址

代表终结点地址类型的EndPointAddress对象的Uri属性仅仅代表服务的逻辑地址。而我们所说的物理地址,对于服务器来说是监听地址。对于客户亿来说则是消息真正发送的目标地址。在默认情况下,物理地址和逻辑地址是统一的,但是由于网络环境的限制,我们需要实现逻辑地址与物理地址的分离。

2.4.1 服务器的角色

2.4.2 监听地址与监听模式

ListenUri

ListenUri可以通过配置的方式制定,表示服务端终结点的配置节点(services/service/endpoint),具有ListenUri属性。如果没有对ListenUri进行显示设置,改属性的值和终结点地址具有相同的URI
也就是说,在默认情况下服务端终结点的逻辑地址和物理地址并不是分离的。

ListenUriMode

当我们设置了终结点的ListenUri属性后,并不意味着该终结点一定会采用这个URI进行请求监听。
最终的监听地址还具有另一个决定性因素,那就是监听模式。

ListenUriMode的两个枚举分别表示两种决定最终监听地址的方式。Explicit表示严格采用终结点的ListenUri属性设置的Uri作为最终的监听地址,而Unique则根据ListenUri采用不同的策略保证最终使用的监听地址是唯一的。WCF采用如下的策略保证监听地址的唯一性:

如果采用TCP作为传输协议,在不采用端口共享的情况下,会选择一个未被使用的端口作为最终监听地址的端口以确保地址的唯一性。

如果采用TCP作为传输协议,在不采用端口共享的情况下,会添加一个GUID作为后缀以确保地址的唯一性。

对于非TCP作为传输协议,会添加一个GUID作为后缀以确保地址的唯一性。

2.4.3 ClientViaBehavior行为

客户端实现逻辑地址与物理地址的分离是通过一个终结点行为实现的。行为在WCF中是一个非常重要的概念,也是对WCF进行扩展的最为重要的方式。契约是服务端和客户端就某个方面达成的一种共识,是一种双边协议;而行为则是客户端或者服务端本地实现某个功能的一种方式,是一种单边行为。

契约行为和操作行为被定义成特性(Attribute)并分别应用到契约接口/类或者契约接口和服务类型的操作方法之上,而终结点行为则只能通过配置的方式应用到服务端或者客户端节点上;至于服务行为,
既可以采用基于特性声明式的应用方式,也支持配置的应用方式。

服务行为和终结点行为分别定义在behaviors/serviceBehaviors和behavior/endpointBehaviors
服务的配置节点services和终结点的配置节点services/service/endpoint, 在endpoint节点上有一个behaviorConfiguration
,这是用来设置服务行为和终结点行为的。

WCF4.0 还支持默认的行为配置

2.4.4 实例演示:通过tcpTrace进行消息路由(S205, S206)

2.5 请求监听与消息分发

2.5.1 连接请求的监听

2.5.2 消息分发

2014-09-25
WCF全面解析
第2章 Address

时间: 2024-08-29 19:51:43

第2章地址Address(WCF全面解析3)的相关文章

第1章WCF简介(WCF全面解析读书笔记2)

第1章 WCF简介 面向服务架构(SOA)是近年来备受业界关注的一个主题,它代表了软件架构的一种方向.顺应SOA发展潮流,微软于2006年年底推出了一种新的分布式通信框架Windows Communication Foundation,简称WCF.WCF是作为.NET Framework3.0的一个组件发布的. 1.1 SOA基本概念和设计思想 SOA就是采用Web服务的架构吗? 面向服务(Service Orientation,SO)代表的是一种设计理念,和面向对象(Object Orient

iOS- 如何从Boujour里解析出IP地址(sockaddr *的解析)?

1.前言 之前有网友跟我留言说到: 如何从Boujour 解析完的数组里解析出ip地址? 因为Boujour本身解析完毕之后的addresses是一个数组 那我们如何从这个数组里解析出我们需要的IP地址呢? 关于Boujour的使用,读者可以参考我之前写的一篇文章 iOS- Apple零配置网络协议Bonjour的使用? 2.将数组里的数据转换成sockaddr  2.1.在Boujour解析完后会进入下面这个代理方法 在这个方法里我抛出了一通知并将数据传出 2.2.在监听到通知之后我们开始将数

swift禁用webView对H5中数字,链接,日期,地址,电话号码做解析

showWebView.dataDetectorTypes = .None //swift禁用webView对H5中数字,链接,日期,地址,电话号码做解析 其UIDataDetectorTypes属性: static var PhoneNumber: UIDataDetectorTypes { get } // Phone number detection static var Link: UIDataDetectorTypes { get } // URL detection static v

第七章、epub文件处理 -- 解析 .xhtml文件 (一)

第七章.epub文件处理 -- 解析 .xhtml文件 (一) 本章将介绍代码如何利用ZLTextPlainModel类来分别处理.xhtml文件中的文本信息与标签信息. 本章涉及的核心类是ZLTextPlainModel类.ZLTextWritablePlainModel类.CachedCharStorage类.XHTMLTagAction接口实现类 .xhtml文件中包含着两种信息:文本信息与标签信息.我们需要先正确解析出标签信息代表的结构,才能正确得将文本信息显示在屏幕上. 举个例子:(这

第六章、epub文件处理 -- 解析container文件与.opf文件

第六章.epub文件处理 -- 解析container文件与.opf文件 这一章我们会接着第三章结尾介绍的FBReaderApp类的openBookInternal继续,开始介绍解析container文件与.opf文件. 这一章中会涉及到第二章.第四章.第五章中介绍的内容,大家可以互相参照,加深理解 首先,我们来回顾下第四章"epub文件处理 -- epub文件内部组成"的内容.我们在第四章中曾经介绍过,epub文内部包含的文件包括"container.xml文件..opf文

前面部分(WCF全面解析1)

WCF全面解析 [同力推荐] 我经历了COM时代,一直把Don BOx的<COM本质论>奉为我的指路明灯.能把SOA机理和WCF这种特定厂商实现的技术讲得如<COM本质论>一样完美透彻的,那么必属Artech这本经过自己深研.实践而著的心血结晶——<WCF全面解析>.如果你想成为SOA和 WCF方面的专家,那么这本书就是你最好法宝.想想你作为作家而获得的回报,那么你对这本书购买所付出的,简直太值了. ——<走出软件作坊>作者 首先,作者是一位在一线的优秀WC

NAT(地址转换技术): Network Address Translation Protocol解析

版权声明:本文为@小小呆原创文章,出处! https://blog.csdn.net/gui951753/article/details/79593307 目录 NAT产生背景ip地址基础知识NAT技术的工作原理和特点静态NAT动态NATNAT重载(经常应用到实际中)NAT技术的优缺点优点缺点NAT穿越技术应用层网关(ALG)ALG的实际应用NAT技术的未来参考文献 NAT产生背景 今天,无数快乐的互联网用户在尽情享受Internet带来的乐趣.他们浏览新闻,搜索资料,下载软件,广交新朋,分享信

更换zigbee设备导致节点地址冲突的流程解析

目前公司商用的协议栈程序是支持分节点地址可配置的,与zigbee2007pro有很大的不同,因此也产生了一些问题,特别严重的就是本篇所讲述的更换设备导致的现象.本篇将深入代码分析冲突检测及处理的流程,并给出修改方法. 测试使用两个设备模拟冲突场景,A设备先行入网,之后断电,B设备与A设备配置相同的短地址0x0140.当B设备上电后,便产生如下的冲突情景,会影响到正常通讯. A设备的MAC地址为:E3909602004B1200 B设备的MAC地址为:CB909602004B1200 一.冲突情况

空格&lt;&amp;nbsp;&gt;、水平横线&lt;hr/&gt;、地址&lt;address&gt;和&lt;code&gt;标签

空格:   水平横线: </hr> 地址: 一般网页中会有一些网站的联系地址信息需要在网页中展示出来,这些联系地址信息如公司的地址就可以<address>标签.也可以定义一个地址(比如电子邮件地址).签名或者文档的作者身份. <address>标签间的字体默认为斜体: 例如: <address>本文的作者:<a href="mailto:[email protected]">lilian</a> <code&