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的数据传输无需事先打开连接
HTTP是无态的，每次HTTP请求都是相互独立的
HTTP是无连接的，基于HTTP的数据传输无需事先打开连接
HTTPS全称为HyperText Transfer Protocol over Secure Socket Layer(安全超文本传输协议)，它是采用了SSL（Secure Socket Layer）的HTTP，而SSL是一个进行数据加密的协议，很多安全性要求较高的网站都采用HTTPS。
WCF通过HTTPS实现了基于HTTP的传输安全（Transport Security）。
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
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来保证。
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
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）模式下，只能使用私有队列。而访问私有队列需要制定包含队列所在机器名称的路径。
除了普通的用于存储业务数据消息的普通队列之外，还有存储确认消息的管理队列、存储消息拷贝的日志队列、存储回复消息的回复队列、存储死信消息的死信队列等。除了基于独立文件的物理队列之外，还有依附于物理队列的子队列。
私有消息队列：因为共有队列需要注册到AD域中，所以它只能用在域（Domain）模式下。在工作组（Work Group）模式下，只能使用私有队列。而访问私有队列需要制定包含队列所在机器名称的路径。
除了普通的用于存储业务数据消息的普通队列之外，还有存储确认消息的管理队列、存储消息拷贝的日志队列、存储回复消息的回复队列、存储死信消息的死信队列等。除了基于独立文件的物理队列之外，还有依附于物理队列的子队列。
WCF下基于消息队列的URI具有net.msmq前缀。在主机名和队列名称之间通过字符Private表示私有队列，而对于公有队列的URI，表示队列类型部分则不是必需的。下面给出了两个Net.Msmq地址。
net.msmq://artech.com/myservices(公有队列)
net.msmq://artech.com/private/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作为后缀以确保地址的唯一性。
如果采用TCP作为传输协议，在不采用端口共享的情况下，会选择一个未被使用的端口作为最终监听地址的端口以确保地址的唯一性。
如果采用TCP作为传输协议，在不采用端口共享的情况下，会添加一个GUID作为后缀以确保地址的唯一性。
对于非TCP作为传输协议，会添加一个GUID作为后缀以确保地址的唯一性。
2.4.3 ClientViaBehavior行为
客户端实现逻辑地址与物理地址的分离是通过一个终结点行为实现的。行为在WCF中是一个非常重要的概念，也是对WCF进行扩展的最为重要的方式。契约是服务端和客户端就某个方面达成的一种共识，是一种双边协议；而行为则是客户端或者服务端本地实现某个功能的一种方式，是一种单边行为。
契约行为和操作行为被定义成特性（Attribute）并分别应用到契约接口/类或者契约接口和服务类型的操作方法之上，而终结点行为则只能通过配置的方式应用到服务端或者客户端节点上；至于服务行为，
既可以采用基于特性声明式的应用方式，也支持配置的应用方式。
既可以采用基于特性声明式的应用方式，也支持配置的应用方式。
服务行为和终结点行为分别定义在behaviors/serviceBehaviors和behavior/endpointBehaviors
服务的配置节点services和终结点的配置节点services/service/endpoint, 在endpoint节点上有一个behaviorConfiguration
，这是用来设置服务行为和终结点行为的。
服务的配置节点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
WCF全面解析
第2章 Address