|
着名Windows专家《Windows Internals》一书作者Mark Russinovich近日在其Blog上对近几天一些论坛上提出的Windows Vista在播放多媒体文件时导致网络速度严重减慢提出了解释他在博客中提到 很多人正确地指出了导致媒体播放时网络性能下降问题的根源在于多媒体类计划程序(MMCSS)一项曾在Technet杂志上连续三期介绍的Vista内核新改变多媒体播放需要媒体流具有一个稳定的速率否则当要求达不到时播放就会出现卡的现象MMCSS服务运行于服务宿主Svchostexe 中它自动提升音视频播放的优先级以防止其他软件过分占用播放软件应得到的CPU时间 当一个多媒体应用程序开始播放多媒体API自动请求MMCSS服务在每毫秒中的最多毫秒时间将其播放线程的优先级提升至级别的最高级 (Realtime)而这决定于播放线程需要多少CPU时间由于其它线程运行在动态优先级以下就算是CPU占用相当大的应用程序都不会影响播放 你能够通过在WMP中播放一段音视频剪辑来看到这一变化在播放时运行可靠性与性能监视器(perfmonexe)选中性能监视器在Thread对 象中对所有WMPlayerexe的线程加入Priority Current选项将图像范围调整至(Windows中最高优先级)你就能够轻易看到被提升的线程在这里是优先级 不仅是其他线程的活动媒体播放也能受到网络活动的影响当一个数据包到达系统触发一个CPU中断将会使网络设备的驱动程序执行一个中断服务程序 (ISR)其它设备的中断请求在ISR运行时将被阻止因此ISR通常用于执行一些设备记录并且在一个DPC(Deferred Procedure Call)中进行一些在一个更长的数据传输当DPC在中断启用的状态被执行它们将无视优先级而优先于任何线程因此可能对媒体播放线程造成沖击 而网络DPC的处理要求几乎是最高的因为它将把数据包传送至TCP/IP驱动这需要长时间的计算才能完成TCP/IP驱动校验每个数据包确定每个 包使用的协议更新连接状态寻找接收应用程序并将接收到的数据复制到应用程序的缓沖区内这一个Process Explorer截图显示了当我将一个大文件复制到其它系统时DPC的CPU占用率的上升 在Vista开发时对MMCSS的测试中发现即使增加线程优先级大规模的网络传输也会使长时间运行的DPC影响到播放线程因此MMCSS将会发送一条消息至NDIS驱动使其每毫秒仅传输个数据包(每秒万个) 标准以太网的帧大小大约为字节万个包每秒的限制使得速度被限制在兆每秒左右这对于百兆网络没有影响但将会使千兆网络的性能下降到最大值的% 同时在NDIS的这段限制代码中一个BUG将使得这种限制在多网卡的系统中放大比如如果你有一台同时拥有有线和无线网卡的机器这个限制将扩大到包/秒而三块网卡时则进一步扩大到包/秒这个限制此时在百兆网络上也显而易见 我在我的网卡笔记本上也发现了这一限制在我向另一台机器复制文件的同时我打开WMP播放音乐任务管理器显示千兆网络的使用率从%降低至% 你能通过在性能监视器视图的Network对象中添加每秒接收数据包来监视NDIS的数据包接收情况下面你能看到我在实验中接收数据率的变化NDIS处理的数据包数没有达到的理论最大值可能是因为与对方机器进行的连接准备有关 就算限制如此之大Internet传输也不会受影响因为多次中转远远降低了数据包的传输率 Vista的这个限制来自在百兆网络上高传输率的同时达到低延迟流畅播放的实验结果这个硬编码的限制是短视的它忽略了今日多处理器系统和千兆网络普及的现状现在Windows的网络开发组正和MMCSS组共同努力开发一个补丁来应对此问题 (译者评论不是一个BUG是一个功能难道为了那该死的多媒体组件就要牺牲网络性能?那些超高端的视频编辑系统通过千兆网编辑文件服务器 上那些码率上百Mbps的低压缩率高清视频素材这样一来不就卡到死了吗?再进一步说如果Windows Server 正式版上这个MMCSS服务还是默认启用的那么攻击者就有了一种新的DoS服务器的方法只要他有服务器的一般用户权限上去一放歌 外面疯狂DDoSCC服务器的当机还会远吗?) 在评论中有人提出了解决方案 修改注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Audiosrv\DependOnService 将Windows Audio服务的依存服务选项中的MMCSS服务去掉 再禁止MMCSS服务就能破解掉这一限制 |
