下面假设我的机器 A ，同时在机器 B 下载和上传到机器 C。在 A 和 B 建立 TCP 连接时，会通知 B 自己的 TCP Receive Window Size (RWIN_A)，这个值就是 B 可以持续发送多少字节而不需要来等待 A 的 ACK 包的上限。很显然，A 到 B 的 ACK 是上传过程，其延时也决定了 B 向 A 发送数据的速度。假如 A 到 C 的上传也接近饱和的话，那么该 ACK 包就要经过较长的时延才能到达 B 。一样的道理，C 每接收到自己设定的的 RWIN (RWIN_C)字节就要向 A 发 ACK ，也需要挤进 A 的下行通道中。最终的结果就是相互影响，无论上行下行都不可能达到饱和。在上下行不对称的情况，自然是带宽较小的上行通道更接近饱和值，因为 C 到 A 的 ACK 更容易“插队”一些罢了。
最理想的情况是：当 A 接收到从 B 来的 RWIN_A 字节时，正好 A 也向 C 发送了 RWIN_C 的数据，正停在那儿等 C 的 ACK 呢！ 这时 A 到 B 的 ACK 见缝插针发送出去，从 C 来的 ACK 也刚好回来了。于是乎上传下载各行其道，互不影响。理论上要达到这样的效果， RWIN_A 和 RWIN_C 的比例应该就刚好是 A 的上传和下载的带宽之比，对 1M/512k bps 的ADSL ，RWIN_A= 2* RWIN_C。
这当然太理想化了。然而，不管怎么说提高自己的 RWIN 值对宽带特别是上行较窄来说是非常重要的，实际上以我所见那是所谓“宽带优化”中唯一有用的值。
另外，从上面的分析来看,UDP传输就应该没有，至少是较小受这种影响。
EM是和QQ一样使用UDP的
所以对于EM来说,就不会有这种现象(上传影响下载)
而其他那些使用TCP协议来传输的软件
象FTP软件,PP点点通,DC++之类,就会受到影响
