我在VPC的Amazon EC2内部有一组服务器。 在这个VPC内部，我有一个私有子网和一个公有子网。 在公共子网中，我在t2.micro实例上build立了一个基本上运行这个NAT脚本的NAT机器，将规则注入到iptables中。 从私人子网内的机器上从互联网上下载文件可以正常工作。
但是，我将直接从我的NAT机器上的外部高带宽FTP服务器上的文件的下载速度与我私有子网内的机器（通过同一个NAT机器）的下载速度进行了比较。 有一个非常显着的差异：从NAT机器大约10MB / s，从私有子网内的机器下载1MB / s。
NAT机器上没有CPU使用，所以这不是瓶颈。 当用较大的机器（具有“中等networking性能”的m3.medium和具有“高networking性能”的m3.xlarge）尝试相同的testing时，我也不能获得大于2.5MB / s的下载速度。
这是一个一般的NAT问题，可以（也应该）调整？ performance下降从何而来？
更新
通过一些testing，我可以缩小这个问题的范围。 从2013年起，当我使用Ubuntu 12.04或Amazon Linux NAT机器时，即使在最小的t2.micro实例上，一切运行也能顺利进行，并获得完整的下载速度。 无论我使用PV还是HVM机器都无关紧要。 这个问题似乎与内核有关。 这些旧机器具有内核版本3.4.x，而较新的Amazon Linux NAT机器或Ubunut 14.XX具有内核版本3.14.XX。 有什么方法可以调整较新的机器吗？
我们终于find了解决办法。 您可以通过在NAT机器上运行（以root身份）来修复下载速度：
ethtool -K eth0 sg off 这将禁用分散收集模式，（据我所知），停止卸载网卡上的一些networking工作本身。 禁用此选项会导致客户端CPU使用率更高，因为CPU现在必须自行完成工作。 但是，在一台t2.micro机器上，当下载DVD映像时，我们只看到了大约5％的CPU使用率。
请注意，这将无法在重新启动后存活，因此请务必在rc.local设置或至less在设置NAT之前进行设置。
我也在生产中使用类似设置的NAT盒子，因此对您的研究结果非常感兴趣。 在制作之前我还没有得到类似的发现，但可能是我以前没有注意的问题。
让我们来做一些科学！
================================================== ==========================
理论：NAT盒子可以下载和上传更快，那么使用NAT的客户端。
实验：匹配提问者实验。 带有Amazon NAT的t2.micros 2014.09具有NAT的2个子网转到指向NAT的IGW和专用子网。 （共享租赁，通用SSD）
程序：
# install speedtest $ sudo yum install python-pip -y --enablerepo=epel; sudo pip install speedtest-cli # run against the same server $ speedtest-cli --server 935 --simple # run it many times $ for ((n=0;n<10;n++)); do speedtest-cli --simple --server 935; done
数据：
Nat: Client Download 727.38 157.99 Upload 250.50 138.91
结论：OP不撒谎。
================================================== ==========================
理论：不同的内核版本会导致不同的结果。
实验：设置3个nat盒子，每个盒子都有磁性SSD，m3.medium（没有破裂）和专用租户。 运行速度testing。
程序：见上一个实验。 另外，为每个NAT盒子设置一个路由表。 使用黑洞路由表来certificate交换路由表时传播的变化。
curl google.com作品。 curl google.com在客户端上失败。 curl google.com作品。 这里是我的3个nat框：2014.09 3.14.20-20.44.amzn1.x86_64 2014.03 3.10.42-52.145.amzn1.x86_64 2013.09 3.4.62-53.42.amzn1.x86_64
数据：
运行speedtest-cli --server 935时，所有3个盒子的结果都非常相似
09/14 03/14 09/13 355.51, 356.55, 364.04 222.59, 212.45, 252.69
从客户端：
09/14 03/14 09/13 351.18, 364.85, 363.69 186.96, 257.58, 248.04
结论：是否有退化？ 不。内核版本有什么区别？ 没有。
================================================== ==========================
理论：专用与共享租赁有所不同。
实验：2个NAT盒子。 两者都使用NAT 2014.09。 一个拥有共同的租赁权，一个拥有专门的租赁权。
数据：两个盒子都有类似的performance：
Shared Nat Dedicated Nat 387.67 387.26 296.27 336.89
他们也有类似的标准偏差：
$ python3 >>> import statistics >>> shared_download = [388.25, 333.66, 337.44, 334.72, 338.38, 335.52, 333.73, 333.28, 334.43, 335.60] >>> statistics.stdev(shared_download) 16.858005318937742 >>> dedicated_download = [388.59, 338.68, 333.97, 337.42, 326.77, 346.87, 336.74, 345.52, 362.75, 336.77] >>> statistics.stdev(dedicated_download) 17.96480002671891
而当你运行2×2组合时：
Shared Client/Sh. NAT Sh. Client/Dedicated Nat Ded. Client/Sh. Nat Ded. Client/Ded. NAT Upload 290.83 288.17 283.13 340.94 Download 260.01 250.75 248.05 236.06
结论：真的不清楚共享与奉献似乎没有什么大不了。
可能值得重做的testing将是OP对m3.mediums的testing。 我能够复制t2.micro结果，但我的m3.medium似乎与OP的m3.medium结果冲突。
我也有兴趣在内核版本上看到你的数据。
也许最有趣的部分是，我无法得到一个m3.medium NAT快速。
我的testing显示这使我的下载更糟。
m3.large speedtest服务器m3.medium专用NAT服务器。
在这个环境中没有其他的stream量。
sg平均下载速度：292.19 sg平均下载速度：259.21
我的testing是：（（n = 0; n <10; n ++））; 做speedtest-cli –simple; DONE