我创建了一个 SKU 为Standard_D1_v21的Azure VM Southeast Asia。根据本文档，预期带宽为750Mbps。
但是，我测试了本地机器到虚拟机的连接带宽，结果大约是 3Mbps。测试工具是iPerf3，将虚拟机用作 iPerf3 服务器，将我的本地计算机用作 iPerf3 客户端。测试期间虚拟机中没有其他繁重的网络工作负载。我通过远程控制协议遵循了这个结果。
我理解实际带宽会低于预期，原因如下：
- 该连接跨区域且具有多跳。
- 共享基础架构中的虚拟机共享一个总限制（关联）。
- VM 部署到延迟最小的区域（Azure 速度测试）。
但实际带宽（3Mbps）远低于预期（750Mbps）。那么如何：
- 解决根本原因？虚拟机配置错误；跨区域连接跳数过多；还是基础设施某处有节流阀？
- 如何提高本地机器和远程虚拟机之间的带宽？
答案1
如果你做一些非常明显的测试，我会怎么做？这让我怀疑你是否应该在超级用户那里提问，而不是在专业人士的网站上提问。
- 测试两端的带宽。使用从互联网获得的测试 - 很多测试都在浏览器中运行。Speedtest.net 允许您选择对位点，因此您可以从本地服务器开始，然后使用另一端（至少接近），然后在整个路径上挂起自己。
本质上：除非您或另一方有本地问题（这在像您钉住它们这样的滑稽速度水平下不太可能发生），否则这是一个路由问题，您无能为力，除了 2 件事：
- 与您的 ISP 支持人员沟通
- 更换你的互联网提供商。
路由是他们的领域。他们可能搞砸了某条路由 - 但如果没搞砸，那么你除了寻找另一家互联网提供商外别无他法。
您的测试（就其本身而言）毫无用处 - 因为它仅测试 A 到 B - 而不是任何一侧是否存在本地问题。使用我的方法，您可以改变对位，看看您的本地机器在特定目的地是否存在问题。可能是您的本地带宽很好，但国际链接超载了。
如果成功了，就该检查一下所使用的操作系统了。RSS 存在是有原因的，它扩大了“飞行中”数据包的数量，而长 ping 可能需要这些数据包。
除此之外你确实无能为力。
答案2
欢迎来到论坛。
问题在于你无法控制这些点之间的差异。找到这种差异既是科学，也是艺术，因为没有真正好的答案，更多的是一份涵盖多种因素的调查结果报告。
正确定位瓶颈意味着能够测试两侧之间的所有点，您永远无法访问所有点，但您可以推断一些事情并从很多角度查看以获得更好的图像。
您可以排除的问题包括“您这边的吞吐量是否足够？”如果您有一个已知站点，该站点具有专用带宽可供测试，并且有一条已知良好的路由能够维持您的吞吐量，那么您就可以排除“您这边的吞吐量是否足够？”。在线速度测试可能会造成误导，因为您可能拥有足够的连接，而他们可能拥有足够的带宽来可靠地执行测试。但是你们双方都无法控制你们之间发生的事情。如果您在多个测试站点上持续获得良好的速度测试，那么您可以相对安全地排除问题出在您这边，只要您能控制它。当然，另一方面，如果所有站点的故障可能仍然不是您造成的，那么可能是您的 ISP 的 ISP、某个核心网络中的某个人、某条路由关闭导致另一条路由拥塞以保持正常运行等。在这种情况下，如果您可以要求您的 ISP 参与进来，但在消费者线路上，他们会把“速度最高”抛给您，而在专用业务线路上，您有理由，但仍然有举证责任。
虽然这并非不可能，但是瓶颈不太可能出现在 Azure 侧，除非您的合同规定 BW 有限。
你可以使用 MTR 等https://en.wikipedia.org/wiki/MTR_(软件)获得一个大概的概述，但请记住，丢弃 ICMP 可能是系统自然运行的结果，因为大多数网络设备在压力下会丢弃 ICMP，有些只是配置为默认不响应。因此，尽管这可能给你更多的线索，但它并不是确凿的证据，你必须了解如何阅读和解释它。
您可以查看此处https://www.thousandeyes.com/outages/通过全球传感器网络记录重大中断。这有时可以给你提供线索，特别是在 AS 网络（简单来说就是互联网的核心节点）中，如果某个节点出现问题直接影响你的路由。
要解释这一点，并确定“你的”路线是什么，你可以从 HE 的 BGP 工具开始https://bgp.he.net/你将会看到在哪里在互联网中，您处于路由意义上。如果您单击要访问互联网所经过的 IP（通常称为您的公共 IP），您将在那里看到类似以下内容的内容...
这是您在互联网上的身份（访问来源）、您来自哪个网络（宣布为）以及如何进入“互联网”（您的 ISP）
可以从 ASN 追溯到 ASN（自治系统编号），查看您所采取的实际路线（在那个时间点，因为这条路线可能会在没有通知的情况下发生变化以保持路线畅通），甚至可以查看它的图表。
然后，您可以将其与千眼图或大量其他在线 BGP 报告工具进行比较，查看这些路线是否已知拥塞，或者是否出现波动（上下波动）等。
这通常会为您提供足够的信息以通知谁可能负责哪个系统（请注意，大多数人不会关心您的 ISP），尽管这可能无法让您到达您想要的位置，但它解释了为什么您没有到达您想要的位置。
总而言之，你必须这样想，整个互联网的速度并不一致，有些部分通过令人难以置信的快速链接连接，有些则不是。当其中一个大网站出现故障时，许多较小的网站都会受到很大影响。
所以你对此能做些什么？ 有时如果您正在进行点对点连接，则可以绕过它，但是绕过它并不能确保所有走相同路线的客户都能获得相同的体验。例如，您可以在那边有一个 Web 服务器，并且您可能能够与 VPN 提供商之类的服务建立稳定、吞吐量好的连接，该服务位于更靠近您的远程端的位置，并强制它采用更好的路线。如果用户访问您的服务器时不做相同的操作，则不会获得相同的体验。有些服务可以为您提供全套服务，但需要收取一定费用，从而有效地让您的服务器出现在实际位置以外的其他地方，并采用高级路线。可能 cloudflare 有这样的服务，但我从未使用过，所以我必须让 cloudflair 专家对此发表意见。
希望这能让你有足够的理解力，明白这件事情会变得多么棘手，同时也能让你了解你的经历和另一个州的人的经历可能会完全不同。