#1 楼
在WLAN iperf TCP吞吐量测试中，多个并行流将为我提供比1个流更高的吞吐量。我尝试增加TCP窗口的大小，但仅1个流仍然无法达到最大吞吐量。在TCP层中，还有其他事情会阻止使用全部链接容量吗？
以我的经验，如果您看到1个TCP流和多个TCP流之间的结果明显不同，问题通常是丢包；所以TCP层中的“其他”就是重传（由于较低层的数据包丢失）。
我整理了一个示例来说明数据包丢失如何影响单流吞吐量...
[Wifi||LAN-0.0%-Loss||LAN-2.0%-Loss]
+--------------+ +--------------+
| | | |
| Thinkpad-T61 |----------------------------------------| Linux Server |
| | | Tsunami |
+--------------+ +--------------+
iperf client ------------------> iperf server
Pushes data
此表总结了客户端和服务器之间60秒
iperf测试的测试结果...您可能会发现RTPER抖动的iperf结果有些变化（即更高的RTT标准偏差）；但是，最显着的区别是当我模拟2％的损失离开客户端有线NIC时出现的。 172.16.1.56和172.16.1.80是同一台笔记本电脑（运行Ubuntu）。服务器为172.16.1.5，运行Debian。我在客户端有线NIC上使用netem来模拟数据包丢失... Client IP Transport Loss avg RTT RTT StdDev TCP Streams Tput
----------- ---------- ---- ------- ---------- ----------- ----------
172.16.1.56 802.11g 0.0% 0.016s 42.0 1 19.5Mbps
172.16.1.56 802.11g 0.0% 0.016s 42.0 5 20.5Mbps
172.16.1.80 1000BaseT 0.0% 0.0002s 0.0 1 937 Mbps
172.16.1.80 1000BaseT 0.0% 0.0002s 0.0 5 937 Mbps
172.16.1.80 1000BaseT 2.0% 0.0002s 0.0 1 730 Mbps <---
172.16.1.80 1000BaseT 2.0% 0.0002s 0.0 5 937 Mbps
编辑评论响应：
可以您如何解释最后一种情况（1000BaseT，5个流，2.0％的损失）发生了什么？即使存在数据包丢失，总吞吐量仍达到937 Mbits / sec。
大多数TCP实现在检测到数据包丢失时都会减少其拥塞窗口。由于我们使用netem强制从客户端到服务器的2％数据包丢失，因此某些客户端数据被丢弃。 netem在此示例中的净效果是730Mbps的单流平均传输速率。添加多个流意味着各个TCP流可以一起工作以使链接饱和。
我的目标是通过WiFi实现可能的最高TCP吞吐量。据我了解，我应该增加流的数量，以应对由于数据包丢失而导致的吞吐量下降。这个对吗？
是的
另外，什么时候太多的流会开始对吞吐量产生负面影响？这是由有限的内存和/或处理能力引起的吗？
如果没有更多的实验，我无法真正回答这个问题，但是对于1GE链接，我从未遇到过使链接饱和的问题5个并行流。为了让您了解TCP的可扩展性，Linux服务器在适当的情况下可以处理1500个以上的并发TCP套接字。这是另一个与扩展并发TCP套接字有关的SO讨论，但是在我看来，如果您只是想使链接饱和，那么20个以上并行套接字的任何内容都是过大的。一定会误解为iperf使用-w窗口大小作为最大值，这听起来像是您说它的增长超出了21K初始值。我认为有误会。由于您对wifi案例有很多疑问，因此我为wifi单个TCP流案例提供了TCP吞吐量的wireshark图。
测试数据
我还包括原始测试数据，以防您想了解如何测量这些东西...
802.11g，1个TCP流
mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
--report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61 Loss% Snt Last Avg Best Wrst StDev
1.|-- 172.16.1.5 0.0% 60 0.8 16.0 0.7 189.4 42.0
mpenning@mpenning-ThinkPad-T61:~$
[mpenning@tsunami]$ iperf -s -p 9000 -B 172.16.1.5
mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9000 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9000
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.1.56 port 40376 connected with 172.16.1.5 port 9000
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.1 sec 139 MBytes 19.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$
802.11g，5个TCP流
[mpenning@tsunami]$ iperf -s -p 9001 -B 172.16.1.5
mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9001 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.1.56 port 37162 connected with 172.16.1.5 port 9001
[ 5] local 172.16.1.56 port 37165 connected with 172.16.1.5 port 9001
[ 7] local 172.16.1.56 port 37167 connected with 172.16.1.5 port 9001
[ 4] local 172.16.1.56 port 37163 connected with 172.16.1.5 port 9001
[ 6] local 172.16.1.56 port 37166 connected with 172.16.1.5 port 9001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 28.0 MBytes 3.91 Mbits/sec
[ 5] 0.0-60.1 sec 28.8 MBytes 4.01 Mbits/sec
[ 4] 0.0-60.3 sec 28.1 MBytes 3.91 Mbits/sec
[ 6] 0.0-60.4 sec 34.0 MBytes 4.72 Mbits/sec
[ 7] 0.0-61.0 sec 30.5 MBytes 4.20 Mbits/sec
[SUM] 0.0-61.0 sec 149 MBytes 20.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$
1000BaseT，1个流，损失0.0％
mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
> --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61 Loss% Snt Last Avg Best Wrst StDev
1.|-- 172.16.1.5 0.0% 60 0.2 0.2 0.2 0.2 0.0
mpenning@mpenning-ThinkPad-T61:~$
[mpenning@tsunami]$ iperf -s -p 9002 -B 172.16.1.5
mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9002 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9002
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.1.80 port 49878 connected with 172.16.1.5 port 9002
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 6.54 GBytes 937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$
1000BaseT，5个流，损失0.0％
[mpenning@tsunami]$ iperf -s -p 9003 -B 172.16.1.5
mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9003 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9003
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 7] local 172.16.1.80 port 47047 connected with 172.16.1.5 port 9003
[ 3] local 172.16.1.80 port 47043 connected with 172.16.1.5 port 9003
[ 4] local 172.16.1.80 port 47044 connected with 172.16.1.5 port 9003
[ 5] local 172.16.1.80 port 47045 connected with 172.16.1.5 port 9003
[ 6] local 172.16.1.80 port 47046 connected with 172.16.1.5 port 9003
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 1.28 GBytes 184 Mbits/sec
[ 5] 0.0-60.0 sec 1.28 GBytes 184 Mbits/sec
[ 3] 0.0-60.0 sec 1.28 GBytes 183 Mbits/sec
[ 6] 0.0-60.0 sec 1.35 GBytes 193 Mbits/sec
[ 7] 0.0-60.0 sec 1.35 GBytes 193 Mbits/sec
[SUM] 0.0-60.0 sec 6.55 GBytes 937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$
1000BaseT，1个流，2.0％损失
mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc add dev eth0 root netem corrupt 2.0%
mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61 Loss% Snt Last Avg Best Wrst StDev
1.|-- 172.16.1.5 1.7% 60 0.2 0.2 0.2 0.2 0.0
mpenning@mpenning-ThinkPad-T61:~$
[mpenning@tsunami]$ iperf -s -p 9004 -B 172.16.1.5
mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9004 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9004
TCP window size: 42.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.1.80 port 48910 connected with 172.16.1.5 port 9004
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-64.1 sec 5.45 GBytes 730 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$
1000BaseT，5个流，丢失2.0％
[mpenning@tsunami]$ iperf -s -p 9005 -B 172.16.1.5
mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9005 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9005
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 7] local 172.16.1.80 port 50616 connected with 172.16.1.5 port 9005
[ 3] local 172.16.1.80 port 50613 connected with 172.16.1.5 port 9005
[ 5] local 172.16.1.80 port 50614 connected with 172.16.1.5 port 9005
[ 4] local 172.16.1.80 port 50612 connected with 172.16.1.5 port 9005
[ 6] local 172.16.1.80 port 50615 connected with 172.16.1.5 port 9005
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 1.74 GBytes 250 Mbits/sec
[ 7] 0.0-60.0 sec 711 MBytes 99.3 Mbits/sec
[ 4] 0.0-60.0 sec 1.28 GBytes 183 Mbits/sec
[ 6] 0.0-60.0 sec 1.59 GBytes 228 Mbits/sec
[ 5] 0.0-60.0 sec 1.24 GBytes 177 Mbits/sec
[SUM] 0.0-60.0 sec 6.55 GBytes 937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$
删除分组丢失模拟
mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root
评论
您能否解释一下最后一种情况（1000BaseT，5个流，2.0％的损失）发生了什么？即使有数据包丢失，总吞吐量仍达到937 Mbits / sec。我的目标是通过WiFi实现最高的TCP吞吐量。据我了解，我应该增加流的数量，以应对由于数据包丢失而导致的吞吐量下降。这个对吗？此外，过多的流将在什么时候开始对吞吐量产生负面影响？这是由有限的内存和/或处理能力引起的吗？
–elin05
2013年9月17日在18:59
@ elin05：使用多个流将丢包分布在多个流上，因此，当发生丢包时，只有一个流将减小其TCP窗口的大小，而其他流则不受影响。
–BatchyX
2013年9月18日在7:17
802.11g（54Mbps）BDP是否不要求54KB的窗口大小以及8ms（16ms RTT / 2）的延迟，以使管道中充满机载数据包？服务器端的窗口大小是多少？
–generalnetworkerror
2013年9月18日在8:17
@ generalnetworkerror，TCP窗口不是静态的...它们会根据TCP的需要而变化...在该捕获期间，Tsunami公告的最大窗口大小为1177600字节；海啸的平均窗口为1045083字节，在那60秒的测试中，平均RTT为32.2ms。
–迈克·彭宁顿
13年9月18日在11:44
@MikePennington：我一定会误会为iperf使用-w窗口大小作为最大值，这听起来像是您在说它的增长超过了21K的初始值。
–generalnetworkerror
13年9月24日在7:46
#2 楼
这是单个tcp流的最大吞吐量的计算。(TCP Window [bytes]/RTT[seconds]) * 8 [bits/byte] = Max single tcp throughput in (bps)
因此，您将遇到瓶颈，而延迟会发挥很大的作用。
评论
您观察到多少差异？理想情况下，如果一个TCP流提供的吞吐量为T，则两个TCP流应分别提供的吞吐量为T / 2。请注意，无论流数量如何，都将永远无法达到完整的链接容量。具有最少[IP + TCP]标头的IPv4将产生约95％的通道效率。请参阅sd.wareonearth.com/~phil/net/overhead上出色的协议开销发布。
@ManojPandey，我不确定他是否看到了理想的情况……尤其是因为他正在使用wifi ...我怀疑他有一些数据包丢失...
TCP通过Wi-Fi进行处理。如果必须使用它，并且看到第3层数据包丢失，我建议增加第2层最大重试计数，因为TCP并非旨在处理有损链接而不破坏性能。