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