18,356
社区成员
发帖
与我相关
我的任务
分享网络限速方法?
比如像BT这样的软件，可以对上传和下载进行最大速度的限制，但是，这个限速的原理是什么？肯定先排除Sleep。
我搜了一下，有提到下载端不要快速地读掉socket缓冲区中的数据，而是定时的去读，这个道理可以理解，但是，这有一个问题，定时去读的话，会导致socket的缓冲区经常处于满状态，速度是限制了，但是，传输速度却也高不了。我想到的是，同样是从TCP缓冲区的角度去考虑，利用TCP滑动窗口机制，当我检测到接收端的速度达到临界值之后，我把滑动窗口的大小马上改为很小很小，1byte，或者0，socketopot里面不知道有无这个操作。通过这样的操作，使得发送端这个时候只能发送微小的数据，但是又不能不发，当速度降下来之后，又把窗口的值慢慢改大，一个动态的过程。
不知道限速的做法有经验的都是怎么弄的？真心求教~
我搜了一下，有提到下载端不要快速地读掉socket缓冲区中的数据，而是定时的去读，这个道理可以理解，但是，这有一个问题，定时去读的话，会导致socket的缓冲区经常处于满状态，速度是限制了，但是，传输速度却也高不了。我想到的是，同样是从TCP缓冲区的角度去考虑，利用TCP滑动窗口机制，当我检测到接收端的速度达到临界值之后，我把滑动窗口的大小马上改为很小很小，1byte，或者0，socketopot里面不知道有无这个操作。通过这样的操作，使得发送端这个时候只能发送微小的数据，但是又不能不发，当速度降下来之后，又把窗口的值慢慢改大，一个动态的过程。
不知道限速的做法有经验的都是怎么弄的？真心求教~
...全文
请发表友善的回复…
发表回复
zjcqoo 2012-11-05
- 打赏
- 举报
需要那么复杂吗？应用层就可以实现的事。
迅雷的限制其实也不准的。比如限制200k，实际速度也有很大的波动。
上传限速很简单，当前1000ms内发送字节快接近上限的话，剩下的时间就不发送数据了。
http下载的话，降低request的间隔时间，或减少线程，每秒收到的数据就变少了。
p2p的话，需要服务器参与。让服务器根据你的速度需求维护数据转发
Joseph-Growth 2012-10-19
- 打赏
- 举报
首先分析这个速度是如何计算的。
发送/接收的频率*缓冲区大小？
如果是这样，我倒有办法帮你。你可以设置接收/发送缓冲区的低水位值的大小。当发送频率大的时候，增大发送缓冲区低水位值。反之。当接收频率大时，增加接收缓冲区低水位值。
这样没准能达到你说的限速问题。
发送/接收的频率*缓冲区大小？
如果是这样，我倒有办法帮你。你可以设置接收/发送缓冲区的低水位值的大小。当发送频率大的时候，增大发送缓冲区低水位值。反之。当接收频率大时，增加接收缓冲区低水位值。
这样没准能达到你说的限速问题。
丧心病狂的我 2012-10-19
- 打赏
- 举报
编程小白菜鸟实习一个，前来观摩学习。
有点懂，但又不是很懂。
有点懂，但又不是很懂。
baoyz 2012-07-10
- 打赏
- 举报
[Quote=引用 9 楼 的回复:]
下载和上传的部分代码应该是你自己写的吧？
我也写过类似的限速下载的程序。加一个速度记录INT。
各线程下载时累加INT的值，当该INT大于设定下载网速是，停止下载代码的运行。
每秒清零一次。
[/Quote]
我就是这么干的 。
下载和上传的部分代码应该是你自己写的吧？
我也写过类似的限速下载的程序。加一个速度记录INT。
各线程下载时累加INT的值，当该INT大于设定下载网速是，停止下载代码的运行。
每秒清零一次。
[/Quote]
我就是这么干的 。
ajsamr88 2012-07-04
- 打赏
- 举报
.防火墙都是这么搞的.
albertcorleone 2012-07-04
- 打赏
- 举报
楼主提的好问题，理论上应该是制造一个count值，超过这个值就不读了。
你所说的慢慢发送，除非是改写驱动，很明显p2p并非这样。
从内核模型说起，tcp/ip协议好像对时间并没有定义，只是一方不停send，一方不停recv。发送时数据放入send buffer，然后再发送出去。如果send buffer已经满了，里边的数据没有发送出去，此时继续调用send会失败或是一直阻塞着，取决于你使用的是同步或是异步模型。recv时道理也相同，recv buffer数据满了时还没有读取就不再接收数据了。所谓的滑动窗口就是这个东西，他通常反映的是对方内核buffer的能力，当对方buffer满了时tcp窗口会通告发送方对方已经无能力接收了，省点力气吧。
setsockopt即使把buffer设置为1，只要网速够快也一样起不到限速的作用。此外，还会因为频繁调用send，recv导致cpu消耗过高，反倒不是一个好选择。最好方案是超过count值就不再发送或接受，此时recv或send方的buffer会迅速被数据充满，从而不再发送数据了，带宽被节约出来给其他程序了。
你所说的慢慢发送，除非是改写驱动，很明显p2p并非这样。
从内核模型说起，tcp/ip协议好像对时间并没有定义，只是一方不停send，一方不停recv。发送时数据放入send buffer，然后再发送出去。如果send buffer已经满了，里边的数据没有发送出去，此时继续调用send会失败或是一直阻塞着，取决于你使用的是同步或是异步模型。recv时道理也相同，recv buffer数据满了时还没有读取就不再接收数据了。所谓的滑动窗口就是这个东西，他通常反映的是对方内核buffer的能力，当对方buffer满了时tcp窗口会通告发送方对方已经无能力接收了，省点力气吧。
setsockopt即使把buffer设置为1，只要网速够快也一样起不到限速的作用。此外，还会因为频繁调用send，recv导致cpu消耗过高，反倒不是一个好选择。最好方案是超过count值就不再发送或接受，此时recv或send方的buffer会迅速被数据充满，从而不再发送数据了，带宽被节约出来给其他程序了。
choday 2011-12-08
- 打赏
- 举报
让他 的send,recv,sendto,recvto,wsa系统函数延时就可以了，目前我就这样做的
自己写lsp或者winsocket hook就搞定
自己写lsp或者winsocket hook就搞定
wlwlxj 2011-12-07
- 打赏
- 举报
应用层加throttle ，异步读取拆分成小的原子块，排队读写网络，大概就是这样，底层方式有点...
meyers_007 2011-12-05
- 打赏
- 举报
RSVP协议
czydxj 2011-12-02
- 打赏
- 举报
提速费劲，限速还能难吗！
用户 昵称 2011-11-28
- 打赏
- 举报
限自己的速，就是边传输 边 计算当前速度，如果网络连不上的话，那么速度就是0就行了。
Yofoo 2011-11-28
- 打赏
- 举报
上传 比如重写send 函数, 如果超出速度, 可以返回失败, 错误用缓冲满
下载 recv 用sleep也是很正常的
下载 recv 用sleep也是很正常的
smwhotjay 2011-11-25
- 打赏
- 举报
[Quote=引用 7 楼 yby4769250 的回复:]
引用 6 楼 smwhotjay 的回复:
限速.限制send recv就行了.防火墙都是这么搞的.
send和recv也是操作socket的缓冲区，如果不让recv或者定时recv的话，又回到了上面那个问题
[/Quote]
防火墙dll hook目标进程啊
引用 6 楼 smwhotjay 的回复:
限速.限制send recv就行了.防火墙都是这么搞的.
send和recv也是操作socket的缓冲区，如果不让recv或者定时recv的话，又回到了上面那个问题
[/Quote]
防火墙dll hook目标进程啊
baoyz 2011-11-25
- 打赏
- 举报
下载和上传的部分代码应该是你自己写的吧？
我也写过类似的限速下载的程序。加一个速度记录INT。
各线程下载时累加INT的值，当该INT大于设定下载网速是，停止下载代码的运行。
每秒清零一次。
我也写过类似的限速下载的程序。加一个速度记录INT。
各线程下载时累加INT的值，当该INT大于设定下载网速是，停止下载代码的运行。
每秒清零一次。
yby4769250 2011-11-23
- 打赏
- 举报
[Quote=引用 6 楼 smwhotjay 的回复:]
限速.限制send recv就行了.防火墙都是这么搞的.
[/Quote]
send和recv也是操作socket的缓冲区，如果不让recv或者定时recv的话，又回到了上面那个问题
限速.限制send recv就行了.防火墙都是这么搞的.
[/Quote]
send和recv也是操作socket的缓冲区，如果不让recv或者定时recv的话，又回到了上面那个问题
smwhotjay 2011-11-23
- 打赏
- 举报
限速.限制send recv就行了.防火墙都是这么搞的.
xhz2000 2011-11-23
- 打赏
- 举报
关注此贴！ 我也有这方面的需求。
yby4769250 2011-11-23
- 打赏
- 举报
[Quote=引用 1 楼 aaadddzxc 的回复:]
崩想了。WINDOWS 下的话就做 NDIS 驱动吧。
[/Quote]
这个功能不会涉及到这么底层的东西吧
崩想了。WINDOWS 下的话就做 NDIS 驱动吧。
[/Quote]
这个功能不会涉及到这么底层的东西吧
yby4769250 2011-11-23
- 打赏
- 举报
[Quote=引用 2 楼 chenjiawei007 的回复:]
NDIS层做驱动是啥都能搞 ，但这层的开发能熟练winpcap的人也不多吧。
说到bt，迅雷都有对下载的限速，这类文件传输都是采用p2p协议，当然像迅雷这样成熟的公司，p2p协议一定丰富了许多自己的算法。
要实现这个功能方式有许多，如果不做限制，如果你带宽良好，传输速率就是服务器数据的比特率。实现可以有两种思路，一：告诉服务器降低比特率，二：客户端接收效率降低。以前自己这样做过，但是……
[/Quote]
第一种思路正是我在考虑的，因为服务器也是自己写的，但是，有一种情况，像从FTP、Web服务器下载，这是服务器都不是自己写的，一思路就不可行。我的服务器协议通道还是很容易扩展的，准备实践一下一思路
NDIS层做驱动是啥都能搞 ，但这层的开发能熟练winpcap的人也不多吧。
说到bt，迅雷都有对下载的限速，这类文件传输都是采用p2p协议，当然像迅雷这样成熟的公司，p2p协议一定丰富了许多自己的算法。
要实现这个功能方式有许多，如果不做限制，如果你带宽良好，传输速率就是服务器数据的比特率。实现可以有两种思路，一：告诉服务器降低比特率，二：客户端接收效率降低。以前自己这样做过，但是……
[/Quote]
第一种思路正是我在考虑的，因为服务器也是自己写的，但是，有一种情况，像从FTP、Web服务器下载，这是服务器都不是自己写的，一思路就不可行。我的服务器协议通道还是很容易扩展的，准备实践一下一思路
chenjiawei007 2011-11-23
- 打赏
- 举报
NDIS层做驱动是啥都能搞 ，但这层的开发能熟练winpcap的人也不多吧。
说到bt，迅雷都有对下载的限速，这类文件传输都是采用p2p协议，当然像迅雷这样成熟的公司，p2p协议一定丰富了许多自己的算法。
要实现这个功能方式有许多，如果不做限制，如果你带宽良好，传输速率就是服务器数据的比特率。实现可以有两种思路，一：告诉服务器降低比特率，二：客户端接收效率降低。以前自己这样做过，但是是个人写着玩的，不是商业级的开发。
说到bt，迅雷都有对下载的限速，这类文件传输都是采用p2p协议，当然像迅雷这样成熟的公司，p2p协议一定丰富了许多自己的算法。
要实现这个功能方式有许多，如果不做限制，如果你带宽良好，传输速率就是服务器数据的比特率。实现可以有两种思路，一：告诉服务器降低比特率，二：客户端接收效率降低。以前自己这样做过，但是是个人写着玩的，不是商业级的开发。
加载更多回复（2）
