wcf加密

① WCF全面解析的前言

「全書之寫印，實系初稿。有時公私瑣務蝟集，每寫一句，三擱其筆；有時興會淋漓，走筆疾書，絮絮不休；有時意趣蕭索，執筆木坐，草草而止。每寫一段，自助覆閱，輒搖其首，覺有大不妥者，即貼補重書，故剪刀漿糊乃不離左右。個中甘苦，只自知之。」
在某個陽光明媚的早晨，我在去上班的公交車上翻看岳南先生的《南渡北歸》的時候，看到上面這段董作賓描述自己寫作《殷歷譜》之甘苦的文字，回想起我寫作這本書的經歷，不禁感慨萬千。我無意將《WCF全面解析》自比煌煌巨著《殷歷譜》，只是覺得人同此心，這段文字正好描述我寫作此書的狀態。
《WCF技術剖析（卷1）》（以下稱《卷1》）於2009年7月正式出版，在此不久我就開始了《卷2》的創作。對於《卷1》的寫作，我還算是游刃有餘，但是寫作《卷2》的難度是我始料未及的。如果像市面上大部分專著一樣只涉及WCF編程，我想《卷2》早在一年之前就已經完成了。但是我在寫作之初就沒有將本書定位為一本純粹的WCF編程書籍，而是決心寫一本「深入肌理」，對WCF進行「庖丁解牛」式剖析的書籍。在沒有任何現成資料可供參考的情況下，我只能通過對源碼的分析來了解其底層的實現原理。為了能夠確保這部分內容的正確性，我編寫了很多的測試程序來證實我的想法。
「探究之深」是本書難以在較短的時間之內交付出版的一個主要原因，而另一個因素則是「涉及之廣」。WCF不是微軟在Windows平台下的閉門造車，而是在設計之初就考慮到了針對開放標準的支持。《卷2》涉及到太多的WS-*規范，比如「異常處理」一章涉及到SOAP；「元數據」一章涉及到WS-Policy、WS-Transfer、WS-MEX和WSDL；「事務」一章涉及到WS-Coordination和WS-AT；「可靠會話」一章涉及到WS-RM；「傳輸安全」一章涉及到WS-Security、WS-Trust 、WS-Secure Conversation和WS-Security Policy；「WCF 4.0新特性」一章涉及到WS-Discovery。對於這一系列的WS-*規范，單單從頭到尾看一遍都需要花費不少時間，而我已經不太記得自己究竟看多少遍了。
《卷1》的整個內容基本上都圍繞著WCF本身，但《卷2》卻涉及到不少的背景知識。為了讓讀者對WCF有一個全面而深刻的了解，我在書中涉及到很多背景知識的介紹。比如「事務」一章中花費了很多文字介紹MSDTC和System.Transactions事務；「並發與限流」一章中有針對同步上下文的介紹；為了讓讀者能夠深入認識可靠會話的實現原理，我將其同TCP協議的機制進行類比；「隊列服務」一章中對MSMQ進行了系統的介紹；「傳輸安全」一章中更是涉及到針對非對稱加密以及NTLM和Kerberos認證原理的介紹。
由於寫作難度不小，加上寫作和資料收集只能在工作之餘進行，所以很多次都有中途放棄的念頭。很有意思的是，每次在我下定決心放棄寫作後沒幾天總是會收到《卷1》的讀者給我的留言，這些留言體現了對《卷1》的肯定，充滿了對《卷2》的期待。讀者的肯定和期待一次次給了我堅持下去的力量，前後經歷了兩年的時間終於完成了《卷2》，這算是對讀者的交代，也是對我自己的交代。
《卷2》完稿之後我開始為《卷1》的再版進行修訂。對於出版後的《卷1》我基本上很少翻看，因為我個人基本上不太喜歡翻看自己寫的東西，包括自己寫的400多篇博客文章。針對《卷1》的修訂讓我第一次完整地閱讀自己寫的東西，經過了寫作《卷2》的「折磨」，讓我對WCF有了更加深刻的認識，於是我基於對WCF最新的理解開始對《卷1》的內容進行大刀闊斧的修改。雖然《卷1》大體上還是保留著原來的結構，但是內容已經發生了巨大的改變。據我粗略估計，改動內容的比率基本上達到一半。
最後我將《卷2》和修訂後的《卷1》給李建忠和呂建偉（阿朱）老師幫忙審閱，李建忠老師建議增加關於WCF REST的內容，於是我在《卷1》中新加了「REST服務」一章。由於新的《卷1》已經難現往日模樣，在本書的策劃編輯張春雨老師的建議下我決定將原《卷1》和《卷2》作為一個整體分上、下冊出版，於是才有了你手中的這本《WCF全面解析》。 「實踐出真知」，不斷地在具體應用中進行實踐是學習WCF最有效的手段。實踐是檢驗真理的唯一標准，通過將所學的WCF知識應用到一個真正的應用之中，才能確保我們掌握的知識的正確性。實踐不但可以鞏固我們的所學，還會讓我們意識到不足。《WCF全面解析》在每一章節都會提供一系列的實例演示，讀者可以單獨下載這163個實例的源代碼。

② WCF和WebService的區別，有什麼優勢

WCF是微軟.NET戰略中的一大集成者，將.NET中各種網路通信技術集成在一起，構成了WCF。而Web Service是一個很通用的概念，在asp.net中就指一個web服務，wcf包含了所有.net以前的網路通信技術，當然也就包含了web service。

③ WCF的發展前景怎麼樣

可以說是ASP.NET Web Service升級版本 ，webservice進行了性能，數據加密、解密，託管宿主等多方面的擴展，最後的WCF是個很成熟的產品，將廣泛用於分布式開發

④ .NET 的 WCF 和 WebService 有什麼區別

微軟論壇的斑竹回答如下：

1.WebService：嚴格來說是行業標准，不是技術，使用XML擴展標記語言來表示數據（這個是誇語言和平台的關鍵）。微軟的Web服務實現稱為ASP.NET Web Service.它使用Soap簡單對象訪問協議來實現分布式環境里應用程序之間的數據交互。WSDL來實現服務介面相關的描述。此外Web services 可以注冊到UDDI中心.供其客戶查找使用。
後來微軟做了ASP.NET Web Service的安全，性能，數據加密、解密，託管宿主等多方面的擴展，稱為WSE系列，這個是過度產品，最高到WSE3.0.後來就是WCF時代。

2.WCF：其實一定程度上就是ASP.NET Web Service,因為它支持Web Service的行業標准和核心協議，因此ASP.NET Web Service和WSE能做的事情，它幾乎都能勝任，跨平台和語言更不是問題（數據也支持XML格式化，而且提供了自己的格式化器）。
但是WCF作為微軟主推一個通訊組件或者平台，它的目標不僅僅是在支持和集成Web Service,因為它還兼容和具備了微軟早期很多技術的特性。
根據微軟官方的解釋，WCF（之前的版本名為「Indigo」）是使用託管代碼建立和運行面向服務（Service Oriented）應用程序的統一框架。它使得開發者能夠建立一個跨平台的安全、可信賴、事務性的解決方案，且能與已有系統兼容協作。WCF是微軟分布式應用程序開發的集大成者，它整合了.Net平台下所有的和分布式系統有關的技術，如Enterprise Sevices(COM+).Net Remoting、Web Service(ASMX)、WSE3.0和MSMQ消息隊列。以通信(Communiation)范圍而論，它可以跨進程、跨機器、跨子網、企業網乃至於 Internet；以宿主程序而論，可以以ASP.NET，EXE，WPF，Windows Forms，NT Service，COM+作為宿主(Host)。WCF可以支持的協議包括TCP，HTTP，跨進程以及自定義，安全模式則包括SAML， Kerberos，X509，用戶/密碼，自定義等多種標准與模式。也就是說，在WCF框架下，開發基於SOA的分布式系統變得容易了，微軟將所有與此相關的技術要素都包含在內，掌握了WCF，就相當於掌握了叩開SOA大門的鑰匙。

⑤ 如何創建通過 WebSocket 進行通信的 WCF 服務

WebSocket是HTML5開始提供的一種瀏覽器與伺服器間進行全雙工通訊的網路技術。在WebSocket API中，瀏覽器和伺服器只需要做一個握手的動作，然後，瀏覽器和伺服器之間就形成了一條快速通道。兩者之間就直接可以數據互相傳送。
Cocos2d-x引擎集成libwebsockets，並在libwebsockets的客戶端API基礎上封裝了一層易用的介面，使得引擎在C++, JS, Lua層都能方便的使用WebSocket來進行游戲網路通訊。
引擎支持最新的WebSocket Version 13。
在C++中使用
詳細代碼可參考引擎目錄下的/samples/Cpp/TestCpp/Classes/ExtensionsTest/NetworkTest/WebSocketTest.cpp文件。
頭文件中的准備工作
首先需要include WebSocket的頭文件。
#include "network/WebSocket.h"
cocos2d::network::WebSocket::Delegate定義了使用WebScocket需要監聽的回調通知介面。使用WebSocket的類，需要public繼承這個Delegate。
class WebSocketTestLayer : public cocos2d::Layer, public cocos2d::network::WebSocket::Delegate
並Override下面的4個介面：
virtual void onOpen(cocos2d::network::WebSocket* ws);
virtual void onMessage(cocos2d::network::WebSocket* ws, const cocos2d::network::WebSocket::Data& data);
virtual void onClose(cocos2d::network::WebSocket* ws);
virtual void onError(cocos2d::network::WebSocket* ws, const cocos2d::network::WebSocket::ErrorCode& error);
後面我們再詳細介紹每個回調介面的含義。
新建WebSocket並初始化
WebSocket.org 提供了一個專門用來測試WebSocket的伺服器"ws://echo.websocket.org"。 測試代碼以鏈接這個伺服器為例，展示如何在Cocos2d-x中使用WebSocket。
新建一個WebSocket：
cocos2d::network::WebSocket* _wsiSendText = new network::WebSocket();
init第一個參數是delegate，設置為this，第二個參數是伺服器地址。 URL中的"ws://"標識是WebSocket協議，加密的WebSocket為"wss://".
_wsiSendText->init(*this, "ws://echo.websocket.org")
WebSocket消息監聽
在調用send發送消息之前，先來看下4個消息回調。
onOpen
init會觸發WebSocket鏈接伺服器，如果成功，WebSocket就會調用onOpen，告訴調用者，客戶端到伺服器的通訊鏈路已經成功建立，可以收發消息了。
void WebSocketTestLayer::onOpen(network::WebSocket* ws)
{
if (ws == _wsiSendText)
{
_sendTextStatus->setString("Send Text WS was opened.");
}
}
onMessage
network::WebSocket::Data對象存儲客戶端接收到的數據， isBinary屬性用來判斷數據是二進制還是文本，len說明數據長度，bytes指向數據。
void WebSocketTestLayer::onMessage(network::WebSocket* ws, const network::WebSocket::Data& data)
{
if (!data.isBinary)
{
_sendTextTimes++;
char times[100] = {0};
sprintf(times, "%d", _sendTextTimes);
std::string textStr = std::string("response text msg: ")+data.bytes+", "+times;
log("%s", textStr.c_str());

_sendTextStatus->setString(textStr.c_str());
}
}
onClose
不管是伺服器主動還是被動關閉了WebSocket，客戶端將收到這個請求後，需要釋放WebSocket內存，並養成良好的習慣：置空指針。
void WebSocketTestLayer::onClose(network::WebSocket* ws)
{
if (ws == _wsiSendText)
{
_wsiSendText = NULL;
}
CC_SAFE_DELETE(ws);
}
onError
客戶端發送的請求，如果發生錯誤，就會收到onError消息，游戲針對不同的錯誤碼，做出相應的處理。
void WebSocketTestLayer::onError(network::WebSocket* ws, const network::WebSocket::ErrorCode& error)
{
log("Error was fired, error code: %d", error);
if (ws == _wsiSendText)
{
char buf[100] = {0};
sprintf(buf, "an error was fired, code: %d", error);
_sendTextStatus->setString(buf);
}
}
send消息到伺服器
在init之後，我們就可以調用send介面，往伺服器發送數據請求。send有文本和二進制兩中模式。
發送文本
_wsiSendText->send("Hello WebSocket, I'm a text message.");
發送二進制數據(多了一個len參數)
_wsiSendBinary->send((unsigned char*)buf, sizeof(buf));
主動關閉WebSocket
這是讓整個流程變得完整的關鍵步驟, 當某個WebSocket的通訊不再使用的時候，我們必須手動關閉這個WebSocket與伺服器的連接。close會觸發onClose消息，而後onClose裡面，我們釋放內存。
_wsiSendText->close();
在Lua中使用
詳細代碼可參考引擎目錄下的/samples/Lua/TestLua/Resources/luaScript/ExtensionTest/WebProxyTest.lua文件。
創建WebSocket對象
腳本介面相對C++要簡單很多，沒有頭文件，創建WebSocket對象使用下面的一行代碼搞定。 參數是伺服器地址。
wsSendText = WebSocket:create("ws://echo.websocket.org")
定義並注冊消息回調函數
回調函數是普通的Lua function，4個消息回調和c++的用途一致，參考上面的說明。
local function wsSendTextOpen(strData)
sendTextStatus:setString("Send Text WS was opened.")
end

local function wsSendTextMessage(strData)
receiveTextTimes= receiveTextTimes + 1
local strInfo= "response text msg: "..strData..", "..receiveTextTimes
sendTextStatus:setString(strInfo)
end

local function wsSendTextClose(strData)
print("_wsiSendText websocket instance closed.")
sendTextStatus = nil
wsSendText = nil
end

local function wsSendTextError(strData)
print("sendText Error was fired")
end
Lua的消息注冊不同於C++的繼承 & Override，有單獨的介面registerScriptHandler。 registerScriptHandler第一個參數是回調函數名，第二個參數是回調類型。 每一個WebSocket實例都需要綁定一次。
if nil ~= wsSendText then
wsSendText:registerScriptHandler(wsSendTextOpen,cc.WEBSOCKET_OPEN)
wsSendText:registerScriptHandler(wsSendTextMessage,cc.WEBSOCKET_MESSAGE)
wsSendText:registerScriptHandler(wsSendTextClose,cc.WEBSOCKET_CLOSE)
wsSendText:registerScriptHandler(wsSendTextError,cc.WEBSOCKET_ERROR)
end
send消息
Lua中發送不區分文本或二進制模式，均使用下面的介面。
wsSendText:sendString("Hello WebSocket中文, I'm a text message.")
主動關閉WebSocket
當某個WebSocket的通訊不再使用的時候，我們必須手動關閉這個WebSocket與伺服器的連接，以釋放伺服器和客戶端的資源。close會觸發cc.WEBSOCKET_CLOSE消息。
wsSendText:close()
在JSB中使用
詳細代碼可參考引擎目錄下的/samples/javascript/Shared/tests/ExtensionsTest/NetworkTest/WebSocketTest.js文件。
創建WebSocket對象
腳本介面相對C++要簡單很多，沒有頭文件，創建WebSocket對象使用下面的一行代碼搞定。 參數是伺服器地址。
this._wsiSendText = new WebSocket("ws://echo.websocket.org");
設置消息回調函數
JSB中的回調函數是WebSocket實例的屬性，使用匿名函數直接賦值給對應屬性。可以看出JS語言的特性，讓綁定回調函數更加優美。四個回調的含義，參考上面c++的描述。
this._wsiSendText.onopen = function(evt) {
self._sendTextStatus.setString("Send Text WS was opened.");
};

this._wsiSendText.onmessage = function(evt) {
self._sendTextTimes++;
var textStr = "response text msg: "+evt.data+", "+self._sendTextTimes;
cc.log(textStr);

self._sendTextStatus.setString(textStr);
};

this._wsiSendText.onerror = function(evt) {
cc.log("sendText Error was fired");
};

this._wsiSendText.onclose = function(evt) {
cc.log("_wsiSendText websocket instance closed.");
self._wsiSendText = null;
};
send消息
發送文本，無需轉換，代碼如下：
this._wsiSendText.send("Hello WebSocket中文, I'm a text message.");
發送二進制，測試代碼中，使用_stringConvertToArray函數來轉換string為二進制數據，模擬二進制的發送。 new Uint16Array創建一個16位無符號整數值的類型化數組，內容將初始化為0。然後，循環讀取字元串的每一個字元的Unicode編碼，並存入Uint16Array，最終得到一個二進制對象。
_stringConvertToArray:function (strData) {
if (!strData)
returnnull;

var arrData = new Uint16Array(strData.length);
for (var i = 0; i < strData.length; i++) {
arrData[i] = strData.charCodeAt(i);
}
return arrData;
},
send二進制介面和send文本沒有區別，區別在於傳入的對象，JS內部自己知道對象是文本還是二進制數據，然後做不同的處理。
var buf = "Hello WebSocket中文,\0 I'm\0 a\0 binary\0 message\0.";
var binary = this._stringConvertToArray(buf);

this._wsiSendBinary.send(binary.buffer);
主動關閉WebSocket
當某個WebSocket的通訊不再使用的時候，我們必須手動關閉這個WebSocket與伺服器的連接，以釋放伺服器和客戶端的資源。close會觸發onclose消息。
onExit: function() {

if (this._wsiSendText)

this._wsiSendText.close();

⑥ Web Service和WCF的到底有什麼區別

Web Service是早期的技術實現了，也是soap的東西，採用的主要是http協議，假如是在C#上開發的話，需要寄宿在IIS上來實現。
WCF的話是相對較新的技術，裡面的basichttpbinding可以跟以前的ws進行通信，並且集成了大部分的通信協議(幾種http協議的實現以及net.Tcp實現、msmq、命名管道等實現)，另外寄宿的宿主可以是命令行控制台、IIS、桌面程序等。
差別的話，感覺有這以下幾點[針對C#來說的]。
ws的話，編程模型沒有wcf的那麼好，具體的實現差別建議網路下，個人覺得wcf比較好。wcf可以用契約的介面方式來進行實現，而ws的話主要是通過繼承WebService的類來實現的，方法上添加WebMethod特性，WCF的話是通過服務契約來聲明(可以是介面也可以是類對象)
ws的話通用性比較強，跟java等ws也可以進行互相通信，然後假如是wcf發布的服務，除了basicHttpBinding這種綁定之外，其餘的幾種綁定基本上不能作為互相通信。例如命名管道跟net.Tcp都是，值得說的是這里的net.Tcp跟原生的tcp是不一樣的，內部實現上參考tcp的可靠連接機制進行了應用層的一套實現。
另外一點就是服務引用跟web引用上的，這個嚴格來說不能屬於兩者的區別，只是.net版本的區別，主要是針對客戶端對服務端發布好的服務進行的引用，服務引用生成的時候，會在配置文件上存在一份配置項，可以進行ABC終結點的配置，假如是web引用的話，會在setting中添加上一個硬編碼的地址。建議用服務引用。
還有一個就是客戶端調用服務端開發的時候，webservice的話，基本上只能通過服務端發布的地址來進行引用[應用的方式可以參考點3]，或者通過服務端提供的wsdl文件來進行引用(該種方式一般比較少，因為需要提供文件，而不是通過公開的方式來進行介面的提供，無法應對服務變更後發布問題，但是確實有這個情況的存在)。而wcf的話，還存在可以通過提供契約文件(就是聲明了ServiceContract的那個介面文件)來進行服務的調用。
在介面層面的話，凡是IList<class T>以及IDictionary<class T>這一類的泛型實現都會在進行服務引用的時候，都會轉換為數組的，例如void F(IList<int>)會在引用後成為void F(int[])這種方式，而才用點4提供的契約文件的話就能保持方法的原始聲明。
個人建議的話，假如是新開發的系統基本上都才用wcf比較好，一個是介面的思想，一個是假如需要轉換為其他協議的話可以比較方便，只需要通過配置文件修改下就可以[當前前提是沒有用到特定協議的特定屬性，例如服務回調，有些協議是不支持雙向通信的]。而且也需要考慮發布的服務是否需要公開給別的語言進行通信。

另外說的性能在下降的話，大概說明下：
基本上針對應用的開發都是基於socket的開發，傳統的socket開發的話，是需要自己去實現整個通信框架的，包括多線程處理，IOCP等的實現[基本上.net的非同步通信模型在內部實現都會綁定好，IOCP是一個非同步模型，自行網路]，二進制流的編碼處理[網路傳輸都是通過二進制的，例如utf8到二進制的轉換]，tcp無邊界消息的處理[udp的話沒有這個，但是包體的大小也是有限制]，通信協議的約定處理[例如ws跟wcf是採用soap這種，各種ws的約定，例如多少個位元組表示數據流的長度、數據的檢驗，還是數據加密位，也包括數據的位移處理]，數據上拋模型跟數據回復模型[接受到數據後是需要上拋給業務層去進行處理的，然後也需要回復給客戶端，不過也不一定是這樣，看需求]，還有各種針對性的處理，例如客戶端socket的保存[有可能對長期不適用的套接字要進行自動斷開的業務]。類似wcf這種東西的話，還有序列化跟反序列化的情況[序列化跟反序列化是性能開銷比較大的，例如序列化是通過反射來實現的，反射又是跟程序集的元數據有關的，屬於運行時行為]，假如是自己實現tcp通信模型，就不一定會有序列化跟反序列化的通信模型了，而且wcf為了讓通信跟本地調用那樣以及標準的方面，位元組流都是比較大的，這里也會增加通信的帶寬【好比自定義的協議4個位元組的數據包長度+1個位元組的加密壓縮位+N個數據包位+X個位元組的檢驗位，這種的話實際用到的位元組就比較少了，因為在數據包裡面，可以會用2個位元組表示協議頭，例如ox0A表示登錄介面，再用4個位元組表示登錄名，4個位元組表示密碼等】。以上是簡單的對socket跟wcf\ws等協議的差別說明。socket跟wcf\ws對比的話，socket性能是最高的，高並發高響應的時候，這里是有差距的，技術上的話，socket需要更加多的技術支持[開發周期長，對人員要求高]，而wcf在應用層面上基本無難度，就是一些配置，出現問題也大部分可以通過網路來處理。另外一個就是託管語言本身的問題，GC這塊的，GC回收的時候，是需要掛起堆棧上的線程的，而且GC的線程優先順序比自己所能創建的所有線程的優先順序都要高，等GC執行完畢的時候才能去執行自己的線程，wcf在堆對象上申請的空間也會更加多，自然導致GC會受到的概率也會更加大，這里也會可能導致wcf性能不如socket。基本上來說，C#的類都是引用對象，都是堆申請的，在引用計數超出的時候，都會被下一個GC[]操作去回收，真是個奇葩的事情。

總之，在ws跟wcf之間選擇的話，個人覺得優先選擇wcf好點。
如果是對性能要求較高[高並發等]，或者是長連接再或者是需要用到UDP這種的話，就基本上無法用wcf跟ws這種了，wcf是沒有udp協議的，http協議也只是在tcp協議下的上層協議，底層發送的數據包跟實作是不通的。另外對於長連接，雖然wcf提供了類似回調這種情況機制，只是個人不推薦使用在這種長連接的場合下。