Linode（现归属Akamai旗下）是历史悠久的老牌云服务商，以性价比高和产品稳定著称。但很多人在选择云主机时只关注公网带宽，忽略了内网吞吐这个关键指标。实际上，无论是数据库主从同步、负载均衡后端通信，还是分布式存储集群的数据复制，都高度依赖实例之间的内网传输能力。本文将对Linode云主机的内网吞吐进行实际测试，从测试方法、不同机型的表现、计费影响等多个角度展开分析，并给出针对性的优化建议。
测试环境与方法说明
本次测试选择了Linode的Newark机房（us-east区域），这是Linode最早的数据中心之一，基础设施成熟。测试实例包括三种规格：Nanode 2GB（共享CPU入门款）、Shared 4GB（共享CPU标准款）以及Dedicated 4GB（独享CPU款），操作系统统一使用Debian 12，内核版本6.1。所有实例部署在同一区域同一可用区内，这是内网通信的前提条件——Linode只有同区域内的实例之间才能走内网通信，跨区域的流量会走公网并产生公网带宽费用。
测试工具主要使用iperf3，这是目前最主流的网络吞吐测试工具。测试前需要确认实例的内网IP地址。在Linode创建实例时，如果账号中开启了VPC（Virtual Private Cloud）功能，实例会自动分配一个内网IP，可以通过ip addr命令查看。测试命令如下：
# 在服务端实例执行，监听5201端口 iperf3 -s # 在客户端实例执行，测试上行吞吐，持续60秒 iperf3 -c 192.168.140.12 -t 60 # 测试下行吞吐（反向模式） iperf3 -c 192.168.140.12 -t 60 -R # 使用多线程压满链路 iperf3 -c 192.168.140.12 -t 60 -P 8
除了吞吐测试，还用ping和mtr测试了内网延迟。需要提醒的是，测试时间建议不低于60秒，短时间的测试容易被瞬间波动干扰，得出的数据参考价值有限。另外建议在不同时段各跑一轮，排除网络高峰期的影响。
实测结果：不同规格的内网吞吐差异明显
测试结果首先给出的结论是：Linode的内网吞吐与实例规格强相关，这一点和很多按量计费内网带宽的云厂商思路一致。实测数据显示，入门级的Nanode 2GB实测内网吞吐在1Gbps左右，基本跑满千兆；Shared 4GB规格可以稳定达到2Gbps上下；而Dedicated 4GB实例在单流模式下就能达到4Gbps以上，使用8线程并行测试时吞吐接近8Gbps。可以看出Linode基本是按照vCPU数量线性分配内网带宽的，每核大约对应1到2Gbps的能力。
延迟方面表现相当不错。三组实例之间的内网往返延迟都在0.3毫秒以内，平均延迟约0.2毫秒，抖动极小，没有出现丢包。这个延迟水平对于搭建需要频繁小包交互的集群（比如Redis哨兵、Consul集群）来说非常友好。内网延迟低意味着TCP三次握手、心跳检测、分布式一致性协议的投票通信都不会成为瓶颈。
对比公网传输，内网的优势是全方位的。同样的两台实例走公网IP互传，iperf3实测吞吐下降约30%，延迟上升到1毫秒以上。更重要的是，Linode的公网流量是计费的（每月包含1TB免费额度，超出后按量收费），而VPC内网流量完全免费。因此凡是实例之间的通信，都应该尽量配置走内网，这既是性能优化，也是成本优化。
影响内网性能的因素分析
第一个因素是实例规格。正如上文的测试数据所示，共享CPU的入门机型内网带宽上限较低，这并不是Linode刻意限制网络，而是共享vCPU本身能处理的网络中断和封包能力有限。如果业务场景是大流量的数据库复制或对象存储同步，至少应该选择Shared标准款，预算充足则直接上Dedicated机型。
第二个因素是是否使用VPC。Linode早期没有原生VPC，实例之间只能通过公网IP通信，既不安全又计费。现在的VPC功能可以在区域内划出私有子网，实例挂到VPC后自动获得内网IP，通信完全隔离于公网。需要注意的是VPC是区域级的，跨区域（比如Newark到Fremont）无法组成内网，跨机房通信依然要走公网。
第三个因素是网络虚拟化开销。Linode使用的是基于KVM的全虚拟化方案，virtio网卡驱动在主流Linux发行版中已经内置，一般无需手动配置。但如果发现吞吐异常偏低，可以检查一下网卡队列数：
# 查看virtio网卡的队列配置 ethtool -l eth0 # 查看网卡卸载能力 ethtool -k eth0 | grep -E "tcp-segmentation|generic-receive"
如果队列数与vCPU数量不匹配，可以尝试用ethtool -L调整，通常能改善多线程场景下的吞吐表现。
优化实例间传输效率的实用建议
第一，业务配置一律使用内网地址。数据库主从复制的配置文件、应用连接缓存服务的地址、Nginx反向代理的后端地址，都应该填写VPC内网IP而不是公网IP。这样既省了公网流量费，又降低了延迟，还减少了暴露在公网上的攻击面，一举三得。
第二，大文件传输考虑用多流并行。实测中单条TCP流在共享机型上往往无法跑满理论带宽，用iperf3的-P参数开4到8条并行流后吞吐提升明显。实际业务中如果是rsync同步大量数据，可以拆分目录并行执行；对象存储迁移则可以多任务并发上传。
第三，调整内核网络参数。高带宽长连接场景下，适当调大TCP缓冲区有帮助：
# 调整TCP缓冲区（写入 /etc/sysctl.conf 后执行 sysctl -p） net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216
第四，合理规划区域部署。把需要高频通信的实例放在同一区域甚至同一VPC子网内，这是获得低延迟内网的根本前提。跨区域容灾架构则要接受公网传输的延迟和费用，把跨区域同步设计成异步、批量化的模式，避免同步复制拖垮业务性能。
总结
总体来看，Linode的内网性能在同价位云服务商中属于扎实的水准：延迟稳定在0.3毫秒以内，吞吐随实例规格线性扩展，Dedicated机型可以提供8Gbps级别的内网带宽，加上VPC内网流量免费的策略，对于中小规模的集群架构相当友好。如果你的业务涉及数据库主从、消息队列集群或分布式存储，建议至少选用Shared 4GB及以上的机型，并把所有实例间通信切换到VPC内网，这样可以在性能和成本两个维度同时获得收益。在正式上生产之前，建议参照本文的iperf3测试方法对自己的实例做一轮基线测试，掌握真实的网络能力上限，为容量规划提供数据支撑。