在查看微软的VS2005 Web测试帮助文档时，发现一个好免费工具。
Fiddler是一个很好的HTTP watcher和debugger，用来监视客户端与服务器的实际HTTP通信内容。可以用于开发和Web测试数据监视。
您可以在http://www.fiddlertool.com/fiddler/下载Fiddler。
前段时间一直很忙，好久没有写博客了。今天忙里偷闲，将前段时间遇到的一个比较经典的问题在此描述一下。希望能帮到遇到类似问题的朋友。
前段时间遇到了一个很奇怪的问题，反复请求一个在线播放页面后，发生父页面所有请求都被锁死，用Fiddler工具也监测不到有任何请求发出，百思不得其解。经过大概一个星期的不断排查，发现播放页面不断向服务器发大数据量的请求，怀疑是请求过多导致拒绝服务。再经过对比问题发生前后的版本文件，终于将问题锁定在播放页面的Atlas服务器端实现方法上。因为以前的版本是使用Web Service 的实现方法，后台改成了PageMethods 的实现方法，之后就出现页面被锁死的问题了。
为了验证自己的猜测，上网查找相关资料，果然发现一些问题。
我们可以用两种方式把一个服务器端方法暴露给客户端Atlas调用：Web Service和Page Method。所有人都应该非常重视的一点是Web Service和Page Method的工作原理以及工作过程有很大的分别。对于Atlas调用Web Service来说，当请求被发送时候，仅仅简单传给服务器方法的参数数据。而对于Atlas调用Page Method来说，传输的数据将会很多，将把表单中所有的域，包括ViewState，一起传送到服务器。在服务器端，它的工作方式也和普通的PostBack很相似：在这个Page Method被调用前，所有的服务器控件将得到它自身的状态。这也正是为什么Page Method中可以访问页面中控件状态的原因。
有人曾经对两种方法做了一个对比实验，通过一段Web Method，只是简单的返回服务器的当前时间。
[WebMethod]
public DateTime GetCurrentDateTime()
{
return DateTime.Now;
}使用Fiddler观察实际运行时的HTTP通信内容，发现Web Service方式运行时Post回服务器的Content-Length为0，而以Page Method运行时候为1718。
上述对Web Service和Page Method方法的描述，更加坚定了我的猜测。立即着手解决我碰到的问题，我将服务端的实现方法改回原来的Web Service，在经过反复测试，果然没有再发生父页面被锁死的问题了。
因此我的建议是只要在确实需要使用Page Method的时候（比如说需要在Page Method中访问页面中的控件状态）才使用Page Method，否则尽可能多地使用Web Service，这样可以使程序在性能上有所提高。使用Web Service的另一个好处是让程序层次架构明晰。
用户登录远程电脑，而远程电脑没有声卡的时候，就无法播放多媒体文件。这种情况下可以使用本地声音设备播放远程电脑上的多媒体。
适用对象：
远程电脑上没有声卡或其他放声设备。
解决办法：
在组策略中设置"允许音频重定向"开启即可。
在命令行中输入gpedit.msc打开组策略管理器，选择"计算机配置－管理模板－Windows组件－终端服务－客户端/服务器数据重定向"打开"允许音频重定向"，然后重新远程登录即可。
允许音频重定向：指定用户是否可以在终端服务会话期间(音频重定向)选择播放远程计算机的音频输出的位置。
可以看到该项上下还有很多重定项的选项，有兴趣的朋友可以自己研究研究。