有一个疑惑，为何家庭宽带上行带宽应用被跑满后，下行带宽应用可能就无法使用了？

上行

下行

带宽

19 条回复 • 2025-01-04 07:04:20 +08:00

1

julyclyde

2 天前

ACK 没办法发出去

2

realpg

2 天前

嘴堵上耳朵不堵能跟人正常交流才怪

3

MuJian

2 天前

下载你首先得请求下载啥吧，堵塞了请求指令都发不出去了。

4

luoshengdu

2 天前

2

恭喜你发现了限速的真谛。

举例，使用 www.panabit.com 识别流量后，限制上行是最佳实践，把迅雷限制到上行 30KB ，那么他的下行只能跑到 20MB 左右。BT 软件同理，限制足够低的上传即可保证它能下载速度又不会影响整体网络体验。 [这是从网络管理视角看问题，请勿用分享精神抨击]

如果我们是限制下行，那么流量都会拥堵在自己的外网侧接口进不来进一步劣化网络体验；通过限制上行，则可以把发起流量的终端控制住，把流量控制在局域网侧的终端到路由链路部分，不让它影响其他用户的网络体验

5

Ipsum

2 天前

占满上行。tcp 的 3 次握手都完不成，当然转圈了。

6

cnbatch

2 天前

上传跑满，SYN 、ACK 都很难发出去，对面会认为传送失败，于是就不再继续发送后续数据，而是重传数据，然而实际上用户已经收到了。由此得到的用户体验就是下行变慢甚至无法使用。

在 ADSL 时代，由于上行带宽太少容易占满导致下行受阻的现象很常见，于是就有公司推出专门的软件，对上行链路的数据包作重新排序，让 SYN 、ACK 之类的数据包优先出去。我还记得其中一个软件叫做 cFosSpeed ，至今还活着。

以上是针对 TCP 而言的（毕竟大多数流量都是 TCP ），对于 UDP 来说未必适合，UDP 有多种暴力发包的玩法。

7

jim9606

2 天前 via Android

可靠传输是需要回 ACK 的，包括那些实现在 udp 上的可靠传输协议
也就流媒体类可以管生不管埋，但多数时候这种业务还是跑在可靠传输上

8

yinmin

2 天前 via iPhone

下行数据同时需要有少量的上行数据包（传输控制数据等）。

你的问题本质上是路由器不行，好些的路由器（如华为）有流量平衡控制算法，不会让某个设备抢占所有带宽，会在设备之间平衡带宽的。

9

hefish

2 天前

哥们，咱这个问题问的很好，以后可以问更加高深的问题了。

10

datocp

2 天前 via Android

这种是 qos 要解决的事情，上行真正的问题是流量伴随并发数限制。

我再次查看了我的 qos 策略，ack 根本没在任何高优先级队列，反而是被注释掉的。优先级 icmp>#ack>syn>fin>rst
而且 openwrt 在 input 方向默认是有 syn 限制

电话线 adsl 观察到的现象，当上行流量超过 80%，伴随着下行流量开始降低。甚至出现无法访问路由器页面的百思不得其解问题。但是有了 qos 以后，类似问题可以解决。但是这个设置上行为总带宽的 80%可不是网上传的在上行位置设置 80%就可以解决了。这个错误高人都是这么传的，难道我的测试结果才是错误？
而在一个像 8mbps 的 adsl 环境，大概并发数在 1200 个左右，此时光靠流量是无法解决迅雷对网络的抢夺，常见的方法就是用 iptables limit 来抑制迅雷的连接数，防止第 1200 个并发数无法发起。

qos ，通过设定不同的流量分组，每个流量分组不同的流量饱合程度，在光纤

11

datocp

2 天前 via Android

在光纤线路可以当上行达到 95%以上才影响下行速度。
而且不同优先级的流量分组，可以让游戏的延迟达到 19ms ，p2p 接近 600ms 。通过流量分组来保证高优先级的游戏，抑制低先级的 p2p 。

这是没有 qos 的线路不具备的，当然你也会发现电信仍然会对一些像英雄联盟之类的游戏做了 qos ，反而本地 qos 设定不当会影响游戏延迟。

按照我的经验，实际上行的高优先级标记是能出现在下行流量上的，此时我只会去设定高优先级的流量拥有 60%的下行，次优先级流量拥有 100%的下行，这样才能让带宽 100%被利用，又可以通过优先级顺序保证高优先级业务通过。

12

starinmars

2 天前

家庭宽带最大的原因还是连接数限制导致的

13

lyu594

2 天前

之前用 qb 下东西就琢磨过为什么下载会跑上传，原来 tcp 会发 ack 包，大约占用数据包的 3.6%-4.2%，也就是千兆宽带至少要 36Mb-42Mb 的上行，不然下载都不达标。

参考 https://www.reddit.com/r/networking/comments/7ru1uw/tcp_ack_packets_provider_upload_limits/