第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