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提供了类似回调这种情况机制，只是个人不推荐使用在这种长连接的场合下。