下载的时候为什么会产生上行? 上行如何限制下载速度
引言 在进行TCP下载的时候, 观察网络, 会发现同时会有"很大"的上行, 比如我的Steam下载 下载速度大概为1000Mbps的时候, 我会产生20Mbps的上行. 同时qBittorrent的[Options]-[Speed]中有一个选项[对传送总开销进行速度限制] 在开启了这个选项, 并且设定一个小于你最大上行的速度限制后, 会发现当你下载速度变高后, 其他种子的上行会随之降低. 这些现象为什么发生, 是本文要探讨的内容. TCP 无论是HTTP下载, 还是BT下载, 所依赖的都是TCP协议. 要了解上述现象, 就要先了解这些行为所依赖的协议. 根据RFC的定义, 当我们下载的时候, 每当Server端发送给我们一个TCP报文段, 我们就要回应一个没有数据的TCP报文段(ACK)表示已经完全收到并请求下一个报文段(暂且不考虑Cumulative Acknowledgment和Delayed Acknowledgment). 举例 具体举例来说: 本地网络设置的MTU是1480, 则Server端TCP报文中, 最大的数据量+TCP头信息就为1480字节. 使用iperf3进行测试(IPv4) Server端发送给我们的内容则为: 名称 报文大小 说明 数据 1480-32=1448 MTU限制了最大数据 IP头 20 TCP头 32 因为包含了OPTION, 所以变大了 Eth头 14 目标MAC, 源MAC, 以太网类型 则我们接收到的一个TCP包大小为1480+20=1514Byte, 但因为MTU限制, 所以最终为1480Byte. 我们的ACK只会包含TCP头,IP头,Eth头, 而不会包含数据, 所以ACK的大小为32+20+14=66Byte. 则我们的上行速率会是实际下载数据速率的$\frac{66}{1480}=4.459459459\%$ 这是在每一个ACK包都对应了一个TCP包情况下的最大占用上行. 在实际的网络请求中, 我们会有累积确认 (Cumulative Acknowledgment)和延迟确认 (Delayed Acknowledgment), 这两种机制会使得我们的ACK包的数量小于接收到的TCP包的数量. 累积确认: TCP 使用累积确认机制, 这意味着接收方发送 ACK 时通常确认的是某一个数据序列号之前的所有数据. 例如, 如果接收方收到序列号为 1 到 100 的数据包, 它可能只发一个 ACK 来确认到 100 序列号为止的所有数据. ...