以编程方式确定最大传输速率
我有一个问题，要求我计算可用的最大上传和下载，然后将程序的使用限制为其中的百分比。但是，我想不出找到最大值的好方法。
目前，我能想到的唯一解决方案是在客户端和服务器之间传输几兆字节，然后测量传输所花费的时间。然而，这个解决方案是非常不可取的，因为对于 100,000 个客户端，它可能会导致我们服务器的带宽使用量增加太多（这已经太高了）。
有人有解决这个问题的方法吗？
请注意，我最感兴趣的是数据离开 ISP 网络之前传输的限制；我认为这很可能会出现导致其他程序通信性能下降的瓶颈。如果我错了，请纠正我。
编辑：经过进一步调查，我认为这是不可能的；涉及太多变量，无法准确测量离开 ISP 网络时的最大传输速率。不过，让问题悬而未决，以防有人想出准确的解决方案。
I have a problem that requires me to calculate the maximum upload and download available, then limit my program's usage to a percentage of it. However, I can't think of a good way to find the maximums.
At the moment, the only solution I can come up with is transfering a few megabytes between the client and server, then measuring how ling the transfer took. This solution is very undesirable, however, because with 100,000 clients it could potentially result in too much of an increase to our server's bandwidth usage (which is already too high).
Does anyone have any solutions to this problem?
Note that I'm mostly interested in the limitation of data transferred up to the point it leaves the ISP's network; I think this is most likely where a bottleneck that would cause other programs' communication to degrade would occur. Correct me if I'm wrong, though.
EDIT: After further investigation, I don't think this is possible; there are too many variables involved to accurately measure the maximum transfer rate when leaving the ISP's network. Leaving the question open, in case someone comes up with an accurate solution, though.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您可以将代码限制为 Windows Vista 或更高版本（不太可能，但谁知道呢？），您可以使用
SetPerTcpConnectionEStats和GetPerTcpConnectionEStats以及TCP_ESTATS_BANDWIDTH_RW_v0让 Windows 估计连接的带宽，然后检索该估计值。然后，根据该估计，您可以限制您使用的带宽。因此，会发生的情况是，您将像现在一样开始运行应用程序，收集一段时间的统计数据，然后根据您在初始时间段内测量的结果实施限制。
这样做的优点是它避免了仅发送额外的数据来收集带宽信息——它只是收集有关您正在发送的数据的统计信息。它有一个缺点（我怀疑这几乎是不可避免的），即它仍然使用接近全带宽的东西，直到您获得可用带宽的估计（并且，如上所述，这是在 Windows Vista 中添加的，因此它甚至不接近全带宽）尚未普遍使用）。
If you can restrict the code to Windows Vista or newer (not likely, but who knows?) you can use
SetPerTcpConnectionEStatsandGetPerTcpConnectionEStatsalong withTCP_ESTATS_BANDWIDTH_RW_v0to have Windows estimate the bandwidth for a connection, and later retrieve that estimate. Then, based on that estimate, you can throttle the bandwidth you use.So what would happen is that you'd start running the application about as you do now, collect statistics for a while, then impose throttling based on what you measure during that initial time period.
This has the advantage that it avoids sending extra data only to collect bandwidth information -- it simply collects statistics on the data you're sending anyway. It has the disadvantage (which I suspect is nearly unavoidable) that it still uses something approaching full bandwidth until you get an estimate of the bandwidth that's available (and, as mentioned above, this was added in Windows Vista, so it's not even close to universally available yet).
如果连接两端都有 Windows 设备，则可以使用后台智能传输服务 (BITS) 来移动信息并解决整个带宽问题。 （几乎）始终安装的组件在 http://msdn.microsoft.com/en-us/library/aa362708(VS.85).aspx" rel="nofollow noreferrer">http:// /msdn.microsoft.com/en-us/library/aa362708(VS.85).aspx。
您没有说是否需要带宽友好性或只是成本问题，因此这可能不合适。
If you have Windows devices on both ends of the connections, you could use the Background Intelligent Transfer Service (BITS) to move the information and cop out of the entire bandwidth question. The (nearly) always installed component is described at http://msdn.microsoft.com/en-us/library/aa362708(VS.85).aspx.
You don't say whether the bandwidth friendliness is required or just a cost issue so this may not be appropriate.
我看到的唯一答案是：
传输率。
1k) 并报告平均值。
一些使问题变得复杂的问题
发送机器（即其他任务
跑步）。
由于客户端可能正在运行其他任务，而主机（发送机器）将运行不同的任务，因此传输速率会有所不同。
我投票赞成发送一块数据计时，发送另一块数据并计时。累积这些持续时间并平均块的数量。这允许动态计时，这比任何预先计算的计时都更准确。
The only answers I see are:
transfer rate.
1k) and report the average.
Some of the issues complicating the matter:
sending machine (i.e. other tasks
running).
Since the client may be running other tasks, and the host (sending machine) will be running different tasks, the transfer rate will vary.
I vote for sending a chunk of data timing it, sending another and timing it. Accumulate these durations and average over the number of chunks. This allows for a dynamic timing, which would be more accurate than any precalculated timing.
如果问题是原始带宽，那么反馈机制可以在这里发挥作用。
当您启动会话时，服务器告诉客户端它将以何种速率发送数据。客户端可以监控其接收数据的速率。如果接收数据的速率低于发送数据的速率（您可以在此处使用阈值，例如低 90% 或更少），则客户端会通知服务器降低数据速率并再次启动该过程。这将作为基本的 QoS 机制。
如果问题是连接具有高延迟和/或抖动，请尝试以较小的数据包（实际的 IP/TCP 数据包）发送信息。通常，系统会尝试使用最大数据包大小，但互联网上的数据包碎片可能会延迟流量。如果这仍然不能改善延迟，那么您可以回退到使用 UDP 而不是 TCP。但这并不能确保数据传输。
If the problem is raw bandwidth then a a feedback mechanism could work here.
When you start the session, the server tells the client at wich rate it will send data. The client can monitor at wich rate it receives data. If the rate for the data received if less than the rate the data is being sent (you could use a threshold here, like 90% lower or less) then the client notifies the server throttle down the data rate and start the process again. This will serve as a basic QoS mechanism.
If the problem is that the connection has a high latency and/or jitter, try to send the information in smaller packtes (actual IP/TCP packtes). Normally the system will try to use the maximum packet size, but the packets fragmentation on the internet could and will delay the traffic. If this still does not improves the latency, then you could fallback to using UDP instead of TCP. But this will not ensure data delivery.
一种选择是在客户端和服务器之间实施 uTorrent 的 UDP 传输协议降低延迟。当其他进程也开始使用带宽时，仅测量原始吞吐量将无济于事，从而减少可用的带宽量。
One option would be to implement something like uTorrent's UDP transport protocol between the client and server to keep latency down. Just measuring a raw throughput won't help when some other process starts using bandwidth as well, cutting down the amount of bandwidth you have free.