推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 3660 天前的主题，其中的信息可能已经有所发展或是发生改变。
requests好像不能限制post上传文件的速率？
 |
1
ss098 2014-10-31 17:25:25 +08:00 via Android
浏览器客户端向服务器发送数据应该不可以限制，但服务器可以限制下载速度，因为发送多少数据是由服务器决定的，但客户端即浏览器发送数据到服务器时倘若服务器限度，但实际上已经有网络数据到达服务器，所以限制是没有用的。
个人理解，若有纰漏，欢迎指正。 |
 |
2
zhengkai 2014-10-31 17:34:54 +08:00
为什么要限制上传……这需求太奇怪了
可以在 nginx 上设定限速（limit_req） |
 |
4
mengskysama 2014-11-01 00:16:16 +08:00  1
|
|
5
ss098 2014-11-01 00:23:16 +08:00
|
 |
6
ryd994 2014-11-01 10:50:18 +08:00 via Android
还有就是TCP窗口小一点
|
|
7
ryd994 2014-11-01 10:53:49 +08:00 via Android
@mengskysama 如果稳定的加上一个延迟的话，TCP完全能够处理，延迟大不是问题，随机性才是
|
|
8
ryd994 2014-11-01 11:04:31 +08:00 via Android
@mengskysama 事实上就是让客户重发，但是别忘了TCP是有拥塞算法的，重发之后就会降速。也就是说给客户端一个拥塞的假象
|
|
9
ryd994 2014-11-01 11:10:33 +08:00 via Android
@mengskysama 缺德一点也可以不改协议层，ipfilter 限制频率drop就行
|
|
10
mengskysama 2014-11-01 12:37:01 +08:00
@ryd994 我没有见到一个软件是这样做的，nginx，libtorrent，transmission等等。您不觉得这是用大炮打鸟吗，我要维持一个速度岂不是要不断丢包？明显不是这样做的。如果在win下面动协议层至少需要ndis，没有软件带这么玩的吧。
|
|
11
ryd994 2014-11-01 17:08:18 +08:00
@mengskysama 丢包只会drop开始那一段超速的，然后客户端的拥塞算法就会认为网络上发生拥塞，发送速度就下来了，然后后面就会一直稳定在这个速率上，既然不超速就不会发生drop。所以尽管浪费了开头那段，但是后面的包是完全没影响的。这只是在无法修改服务器代码时的一种workaround而已。
更文明的办法是调整窗口大小。ack会带上window size。这就是正规的flow control： http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control 你说的控制读socket本质上就是这个，没读走的数据还留在系统缓冲区里，然后ack回去的window size就小了，发送方就会控制速度了。这部分都是系统tcp栈做好的轮子。 如果自己写服务器的话，确实这样做才是正解。 如果写的只是应用的话就该查http服务器的文档。 @zhengkai 你说的limit_req是限制请求频率而非传输速率。应当使用upload_limit_rate： http://wiki.nginx.org/HttpUploadModule#upload_limit_rate |
|
12
mengskysama 2014-11-01 17:46:14 +08:00
@ryd994 第一个TCP拥塞算法里只有遇到丢包才会减小窗口对吧？意味着后面我要不断丢包来保持速度，您觉得合理吗？
第二个，窗口大小和缓冲区大小没有直接联系，窗口大小是拥塞算法给的，这是种特例，就是BUF<CWND |
|
13
ryd994 2014-11-01 18:05:58 +08:00
@mengskysama …………正常的连接也是不停地拥塞，减速，拥塞，减速好吧…………也就是说本来硬件丢掉的，现在软件丢掉而已，是等效的。不是说合不合理，而是说这是你无法控制代码时的唯一方法。
窗口大小不只是拥塞算法给，也会由接收方在ACK中指定，这就叫flow control啊…… http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-2.htm 缓冲区里的数据会减少ack回去的window size，这就是你之前说的方法的实际过程啊，您是不是在4层待太久了,有空也该来三层看看啊。 |
|
14
mengskysama 2014-11-01 18:20:47 +08:00
@ryd994 一般丢包发生在信道比较窄的时候，你用400K信道传输40K基本上不会丢包。
|
|
15
ryd994 2014-11-01 18:24:33 +08:00
@mengskysama 那前提是你只有这点发送啊……如果不额外指定，发送方有什么理由不用满带宽呢？
|
|
16
ryd994 2014-11-01 18:25:29 +08:00
@mengskysama 传输设备hold不住的时候就会扔掉啊
|
|
17
mengskysama 2014-11-01 18:26:20 +08:00
@ryd994 你说的由接收方在ACK中指定，接收方在ACK中指定没错的，但是接收方怎么确定这个大小的，就是通过拥塞算法。
http://baike.baidu.com/view/4521733.htm?fr=aladdin |
|
18
mengskysama 2014-11-01 18:27:58 +08:00
@ryd994 po主要的就是限速啊，如果在理论完美的链路上限速20K，还要不断靠丢包来达到效果我认为不合适吧、
|
|
19
mengskysama 2014-11-01 18:31:25 +08:00
反正不管怎么说都是减小cwnd就对了。
|
|
20
mengskysama 2014-11-01 18:31:45 +08:00
这点上我们2说的是一样的。
|
 |
21
JackWindows 2014-11-02 01:45:17 +08:00 via iPhone
@mengskysama 绝对不是一回事。tcp只是两端window一样而已，发送速率由sender控制，receiver只能通过rfc协定，采用丢包或者ECN(explicity congestion notification)来限制发送方的速率。而且发送端的tcp stack实现可以无节操一点，override rfc协议标准。所以通过服务器端限速绝对是浪费带宽的行为，正常做法是由前端的程序实现限速。
|
|
22
mengskysama 2014-11-02 03:39:31 +08:00 1
@JackWindows 我认同你的观点，我说的一回事是指下载和上传，只是数据流方向不一样，所以不存在下行速度能限制上行速度不能限制的问题。
|
Select Language