ScottGu blogged about the IIS 7.0 Bit Rate Throttling Module being released. Since IIS 7.0 is totally modular (finally!) I think you'll see lots of increasingly useful modules coming out from the team. I know a couple of cool people over there so I get a little insight into what's coming soon.
ScottGu在博客中发布了有关IIS 7.0比特率限制模块的信息。 由于IIS 7.0是完全模块化的(最终！)，我想您会从团队中看到许多越来越有用的模块。 我认识那边的几个很酷的人，所以我对即将发生的事情有一点了解。
Since I'm into podcasting some, I started bugging a PM in the IIS team about the Bit Rate stuff in order to dig deeper into what's going on and how I can exploit it. The next step will be to convince Carl, my producer, that we need to get on this stuff.
由于我正在播客，所以我开始在IIS团队中调试一位PM，了解比特率方面的内容，以便更深入地了解正在发生的事情以及如何利用它。 下一步将是说服我的制片人卡尔，我们需要掌握这些东西。
His Gu-ness has a better description of Bit Rate Throttling that I could write, so here's the meat of it:
我可以写他的Gu-ness对比特率限制进行更好的描述，所以这是它的实质：
Progressive Download Scenario
渐进式下载方案
In a progressive download scenario a client (like Flash or Silverlight) downloads a video directly off of a web-server, and begins playing it once enough video is downloaded for it to play smoothly.
在渐进式下载方案中，客户端(如Flash或Silverlight)直接从网络服务器下载视频，并在下载了足够的视频以使其流畅播放后开始播放。
The benefit of using a progressive download approach is that it is super easy to setup on a web-server. Just copy/ftp a video up to a web-server, obtain a URL to it, and you can wire it up to a video client player. It doesn't require any custom web-server configuration, nor require a streaming server to be installed, in order to enable.
使用渐进式下载方法的好处是，它非常容易在Web服务器上设置。 只需将视频复制/通过ftp发送到Web服务器，获取它的URL，然后就可以将其连接到视频客户端播放器。 它不需要任何自定义的Web服务器配置，也不需要安装流服务器即可启用。
The downside of using a progressive video download approach, though, is that web-servers are by default designed to download files as fast as possible. So when a user clicks to watch a video on your site, your web-server will attempt to transmit it to the client as fast as possible. This is fine if the user decides to watch the entire video. But if the user stops watching the content half way through the video (or navigates to a different page), you will have downloaded a bunch of video content that will never be watched.
但是，使用渐进式视频下载方法的缺点是，默认情况下，Web服务器被设计为尽可能快地下载文件。 因此，当用户单击以在您的站点上观看视频时，您的Web服务器将尝试将其尽快传输到客户端。 如果用户决定观看整个视频，那就很好。 但是，如果用户在视频中途停止观看内容(或导航到其他页面)，则您将下载了一堆永远不会观看的视频内容。
If the remaining un-watched video content is several megabytes (or even tens of megabytes) in size, you will end up over time spending a lot of money on bandwidth that is not benefiting your business/site at all....
如果剩余的未观看视频内容的大小为几兆字节(甚至几十兆字节)，那么随着时间的流逝，您最终会在带宽上花费大量金钱，而这根本无法使您的业务/站点受益。
That's the problem this module tries to solve. If you think it's not a problem, talk to me or Carl. It costs a metric buttload to pay for bandwidth of my podcast and it's a harder problem to solve than you think. (Yes, every show has bittorrent as an option, but few Feed Readers use it). A surprising number of folks visit the site and just click on a show and start listening in whatever Media Player they dig.
这就是本模块要解决的问题。 如果您认为这不是问题，请与我或卡尔交谈。 它花费了公制的负担来支付我的播客的带宽，这是一个比您想象的更难解决的问题。 (是的，每个节目都可以选择bittorrent，但很少有Feed Reader使用它)。 数量惊人的人们访问该站点，然后单击一个节目并开始收听他们挖掘的任何媒体播放器。
If someone starts streaming the first 20 seconds of a 45 minute show, decides they don't like it and stops, we may have to pay for the whole 45 minutes as it might already have been downloaded! This is also good for screencasts.
如果有人开始播放45分钟节目的前20秒，并决定不喜欢并停止播放，那么我们可能需要为整个45分钟付费，因为它可能已经下载了！ 这对于截屏视频也很有用。
The media throttling stuff looks at the file you're downloading, "bursts" the first chunk to make the "buffering" part of your listening experience as fast as possible, then it throttles the bandwidth from that point on, making sure it doesn't have to buffer again, but still saving bandwidth.
媒体限制因素会查看正在下载的文件，“爆裂”第一个块，以使“缓冲”部分尽可能快地成为您的聆听体验，然后从那以后限制带宽，确保它不会不必再次缓冲，但仍可以节省带宽。
There's some technical details over here that I care about like (emphasis mine) and more technical details here:
这里有一些我喜欢的技术细节(强调我的意思)，还有更多技术细节：
"It's also worth noting that the throttler uses a high-performance asyncronous loop to push the data out, without tying up server threads for what can be a very long operation. For responses coming from files (like most large video files), it also does not need to read the content's of the file being sent into memory, instead just instructing http.sys to send portions of the file out to the client at a time. Because of this, it won't significantly affect your memory usage. While this mechanism is not as efficient as http.sys's own site-wide bandwidth throttling (which cannot be used to do what we are trying to accomplish here), it is pretty much as lean as it can be."
“还值得注意的是，调节器使用高性能异步循环将数据推出，而无需占用服务器线程进行很长的操作。对于来自文件(例如大多数大型视频文件)的响应，它也不需要读取正在发送到内存中的文件的内容，而只是指示http.sys一次将文件的一部分发送到客户端，因此，它不会显着影响您的内存使用情况。这种机制不像http.sys自己的站点范围内的带宽限制那样有效(它不能用来完成我们在此要完成的工作)，它几乎可以做到精益化。”
So, I'm going to give this a try on my local machine. I'll start with a recent WMA of the show and put it in a folder under IIS.
因此，我将在本地计算机上尝试一下。 我将从节目的最近WMA开始，并将其放在IIS下的文件夹中。
Notice that this show is a WMA encoded at 32kps (for low-fi/low-bandwidth listeners) and is in http://mymachine/show. I turned on Bit Rate Throttling from the IIS Management Console.
请注意，该节目是以32kps编码的WMA(用于低保真/低带宽侦听器)，位于http：// mymachine / show中。 我从IIS管理控制台打开了“比特率限制”。
You can set the throttle rate as a percentage of the encoded rate. I'm leaving it as 100%, so that's 100% of 32kbps after the initial burst of 20 seconds.
您可以将节流率设置为编码率的百分比。 我将其保留为100％，因此最初20秒突发后就是32kbps的100％。
ASIDE: One of the things that is way better in IIS7 than 6 is dealing with permissions and "blocking issues." You know, when you setup a folder, configure the VDir and you get something like "permission denied" then you spend 20 minutes trying to figure out why you can't serve a freaking text file out of a folder? IIS7 has a "Test Settings" dialog like this that just saved me those 20 minutes.
旁白：在IIS7中比6更好的一件事是处理权限和“阻止问题”。 您知道，当您设置文件夹，配置VDir时，您会得到类似“权限被拒绝”的信息，那么您要花费20分钟的时间来弄清楚为什么不能从文件夹中提供奇怪的文本文件？ IIS7具有这样的“测试设置”对话框，它只为我节省了20分钟。
Ok, back to business. When I hit this file I get the quick burst, then throttling hits to slow it down to a value above, but close to, the encoded rate.
好，回到正题。 当我点击该文件时，我得到快速爆发，然后通过节流击打将其减速到高于但接近编码速率的值。
If I try the hi-fi version of the WMA, you can see the bitrate is higher, so the throttling is smart enough to slow the bandwidth but it's always higher than the encoded rate so there's no skipping.
如果我尝试WMA的高保真版本，则可以看到比特率更高，因此节流足够聪明，可以减慢带宽，但是它始终高于编码率，因此不会跳过。
Here's what the burst followed by the throttling looks like charted.
这是爆发后紧接着节流的样子，如图所示。
Remember that this is just a stock IIS Web Server plus this new module, so we're not running Media Services or a Streaming Server or whatever.
请记住，这只是一个库存的IIS Web服务器加上这个新模块，因此我们没有运行Media Services或Streaming Server或其他任何设备。
使用自定义代码扩展比特率限制 (Extending Bit Rate Throttling with Custom Code)
I thought this was cool and everything, but I immediately brought up the question that some of my users download directly via RSS Readers, while others click the "play now" button and stream. I don't want to throttle the bandwidth for folks who are downloading, just those who stream. However, I'm not running a streaming server (meaning, that everything is over http://, not some mms:// funky port) so I need to differentiate between the two.
我以为这一切都很酷，但是我立即提出一个问题，我的一些用户直接通过RSS阅读器下载，而其他用户则单击“立即播放”按钮并进行流式播放。 我不想限制正在下载的人(仅是流媒体的人)的带宽。 但是，我没有运行流服务器(这意味着所有内容都通过http：//而不是某些mms：//时髦的端口)，因此我需要区分两者。
I figured there were a couple ways to handle this. I could make different VDirs in IIS mapped to the same files and have BRT (Bit Rate Throttling) turned off on one and on for the other. It'd work, but meh.
我认为有几种方法可以解决此问题。 我可以在IIS中将不同的VDirs映射到相同的文件，然后将BRT(位速率限制)关闭，将另一个打开。 可以，但是，嗯。
Or, I could add Windows-Media-Player/11.0.5721.5145 the end of the URL and turn BRT off for those using a custom coded IIS Module.
或者，我可以在URL末尾添加Windows-Media-Player / 11.0.5721.5145，并为使用自定义编码IIS模块的用户关闭BRT。
How to I write a module? I could make a bin folder and build a DLL, etc, but I could also just make an App_Code folder, apply the appropriate permissions...
如何编写模块？ 我可以创建一个bin文件夹并构建一个DLL等，但是我也可以仅创建一个App_Code文件夹，应用适当的权限...
...and put the source for my custom module in it. I actually wrote it in Notepad.
...并将我的自定义模块的源代码放入其中。 我实际上是在记事本中写的。
using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.IO;
namespace Hanselmodules
{
public class CustomBRTModule : IHttpModule
{
public void Init(HttpApplication application)
{
application.BeginRequest += new EventHandler(OnBeginRequest);
}
public void Dispose(){}
public void OnBeginRequest(Object source, EventArgs e)
{
HttpApplication app = (HttpApplication)source;
HttpContext context = app.Context;
if (context.Request.QueryString["download"] == "true") //make these fast
{
context.Request.ServerVariables.Set("ResponseThrottler-InitialSendSize", "60000");
context.Request.ServerVariables.Set("ResponseThrottler-Rate", "6000");
}
}
}
}
Basically, I just check for ?download=true on my URL and set my initial send size and rate to really big numbers. (Certainly they could be bigger, come from config, or be calculated by me.)
基本上，我只是在URL上检查？download = true并将初始发送大小和速率设置为非常大的数字。 (当然，它们可能更大，来自配置或由我计算得出。)
From the Modules section of the IIS Manager I hit Add Module and my new module shows up. I name it and select it and it appears in the web.config in my /show folder.
在IIS管理器的“模块”部分中，单击“添加模块”，然后显示新模块。 我命名并选择它，它出现在我的/ show文件夹中的web.config中。
After installing this module if I hit: http://mymachine/show/foo.wma I get appropriate throttling, and if I hit http://mymachine/show/foo.wma?download=true I don't. Below you can see screenshots of one download finished at 9megs a second while the other is throttled at 28K/s.
安装此模块后，如果我点击了： http：//mymachine/show/foo.wma，我会受到适当的限制，如果我点击了http：//mymachine/show/foo.wma？download = true，我不会。 在下面，您可以看到一次下载的屏幕截图，每秒9兆秒，而另一次的下载速度为28K / s。
Now, this is just one example. I might want to do something cool with JavaScript that appends the ?download if a person clicks a button, or I might want to "sniff" for browser User-Agents versus Media Players like "Windows-Media-Player/11.0.5721.5145" or iTunes/Zune or the like. It's up to me, as writing the IIS7 modules is easy.
现在，这只是一个例子。 我可能想对JavaScript做一些很酷的事情，如果有人单击按钮，它会附加？download，或者我可能想“嗅探”浏览器用户代理与媒体播放器(例如“ Windows-Media-Player / 11.0.5721.5145”)或iTunes / Zune等。 这取决于我，因为编写IIS7模块很容易。
You could even use BRT and techniques like this to throttle bandwidth to data (non-media) files, and give different chunks of bandwidth to different levels of users. My module could have checked if it was a paid user and give them preferred download speeds. Pretty sweet. Now, off to talk to Carl! :)
您甚至可以使用BRT和类似的技术来限制数据(非媒体)文件的带宽，并为不同级别的用户提供不同的带宽块。 我的模块可以检查它是否是付费用户，并为他们提供首选的下载速度。 很甜现在，去和卡尔谈谈！ :)
Related Links:
相关链接：
BRT 32-bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1640
BRT 32位-http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i =1640
BRT 64-bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1641
BRT 64位-http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i =1641
翻译自: https://www.hanselman.com/blog/squeezing-the-most-out-of-iis7-media-bit-rate-throttling
扫一扫
8864
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
