本文算是之前本站网络小故逝系列的一个番外。

其实我想谈的不仅仅是这两个东西，而是笔者从2019年至今，面对运营商日渐拥堵的跨网/跨省链路的一些想法。标题中的『今年』其实是2025年，也就是本文打草稿的时间。全文掺杂大量笔者的思考，如果你也是一个喜欢折腾网络的人，不妨进来看看笔者的胡说八道和天马行空。

我们曾经拥有过『跨网不拥堵』的时代

1. 前言

前言的部分内容基本上是一致的，这里还是不再赘述了，可以通过下面的链接来阅读：

• 几个网络小故逝（第一集）：谁给ISP接网线，什么叫T1/E1
• 几个网络小故逝（第二集）：黑宽带/民营ISP还在神州大地上行走的时候
• 几个网络小故逝（第三集）：IPv6与BGP的乌托邦
• 几个网络小故逝（大结局）：Cloudflare 的那些事

不过本篇作为番外篇，其实还是感觉有必要单独写一份前言，因为如果说之前的网络小故逝都是『听站长讲那过去的事情』，那么本文，其实讲的是目前的事。

2. 那年那网那协议

2.0 水泄不通的链路

最近一段时间，不论是笔者自己的体验也好，间或看到友人的询问和抱怨也好，都出现了『晚上看B站卡』，『晚上看油管卡』，『移动连接电信家宽卡死了』等情况，其表现无外乎都是链路高丢包导致的速度低，这是TCP的特性之一，笔者在之前的博文中有所叙述。和之前一样，友人碰到的问题其实都可以归结为本文的主题，也就是三个拥堵：跨网拥堵，跨省拥堵，跨境拥堵

这里引用上次的截图，可以看到有大量的重传

当然，在开始讨论之前，首先需要明白一件事：我们经常说御三家御三家，但实际上我们碰到的并非 3 个运营商，而是可以看作 3N 个，此处N = 省份数，各省的省公司除了属于同一个企业之外，老实说，互相之间关系真不会那么紧密。

2.0.1 跨省拥堵

跨省拥堵得放到最开始来说，因为差不多可以认为，今天碰到的这些乱七八糟问题，就是跨省拥堵引起的。而跨省拥堵，一般认为，是跨省结算引起的。

大概是自从去年开始吧，如果图库没记录错的话，是2024年年中，『结算费』这个刚刚离开不久的名词，再一次出现在了宽带人的视野当中。我们的主角，跨省结算，简单来说就是，对于上网流量来说，流出省，要向流入省付费。此处的流出省，是站在流量的角度看的，也就是源站位于流出省，用户位于流入省。

网传截图，此处的流出地指的是上面的流入省

乍一听其实很反直觉，因为从一般意义上来说都是受益方付费，也就是流入省付费。其实想要理解这个概念，我们需要一些背景知识：简单来说，后疫情时代，一方面是部分省份的ISP推出低价大带宽套餐用来吸引大客户；另一方面是各大厂（尤其是流媒体大厂）开始降本增效，于是采购大量此类低价带宽，用来覆盖大厂在本省包括临近省份的业务。

我们不妨假设CDN所在省为A省，用户则在BCD...等省，于是这就出现了一个很微妙的事情：大厂付费是付给了A省的ISP，但BCD省用户想要访问A省资源，则是必然需要通过BCD省的ISP才能接到A省的，换句话说，BCD省在帮人家传输流量，但收不上钱来，这还没算BCD省自己本来也有机房，却因为没人买而砸手里的问题。一个不太准确的比方，就好像典型NTR情节里面的苦主，不仅不爽，还得帮黄毛推一把。

此外还有个很典型的问题，省间互联链路容量不一定比省内链路要大，抛开算钱的问题不谈，光是跨省调度CDN这个行为，就足以让省间链路喝一壶了，压力必然会上升很多。

省间结算政策就是在这样的背景下发展起来的，规定流出省付费，相当于是产生流量的一方要交过路费。于是问题就出现在这里 了，我们很自然就能得出一个结论：在运营商的角度看，大家交钱差不多，但只要你跨省上传高，你就是负价值用户，因为运营商的从你这里收到的钱，有一部分需要被拿去付结算费，他的利润自然就少了。

怎么办呢？答案很简单，那就是对跨省链路进行QoS，也就是通过技术手段对流量进行调度，排优先级，如果你是价钱比较高的IDC带宽，或者是大客户，就给你优先级高一些；便宜的家庭宽带用户，或者城域网带宽用户，一边凉快排队去。所以跨省拥堵自然而然地就出现了，我们作为家宽用户，说句不好听的，优先级可以排到最低，自然会在产生跨省流量的时候，被人为地限制，从外部观测来看，就是限速，丢包，产生拥堵。

本来这个措施应该只针对跨省流量的，但运营商不知道是图省事，还是一块钱两头吃，对于省内流量也有类似处理办法，所以上面的认知就变成了只要你上传高，你就是负价值用户。没有了跨省俩字，一般家庭用户也很容易被制裁，也就出现了所谓的『大剪刀』。写那篇文章正好就是一年前，这一年下来，似乎大剪刀有愈演愈烈的趋势了，如果说一开始的取消公网IP以及限制NAT等级，还可以说是限制PCDN，但现在开始直接把大上行用户（包括备份文件到网盘等合法用途）『认为是』PCDN并加以限制，其背后的缘由恐怕并没有那么单纯。

最后补充一点小道消息，听个乐就好：据说部分运营商已经开始取消低价位的SKU，现有用户到期后也不再续签。结合以上猜想，估计运营商现在有点急于甩掉一批低价值用户了。

网图，未经求证，请仔细分辨

2.0.2 跨网拥堵

从2020年起，工信部出台《关于调整互联网骨干网网间结算政策的通知》之后，三大运营商之间的网间结算费，至少从明面上看成为了过去（有小道消息称部分省公司会收，毕竟这份文件只是『骨干网网间结算费』。但关于这个传说并没有明确说法），也就是说三网互联不再需要交结算费了，大家对等互联。

显然，因为御三家的带宽价格并不一致，比如移动的带宽就是要比电信的便宜。在上面的跨省结算政策推出之后，大公司转而变成另一条路子，也就是使用同一省内的低价带宽（如移动）去服务高价区用户（如电信用户）。当然，不是全部CDN都得靠跨网调度，还是有一些会在本网内搞定的，比如热门城市的本网城域网带宽，可能会更便宜。但既然能做出部分流量走跨网调度的决定，就表明大公司内有部分业务是没有那么高SLA需求的，或者说需求不值得增加本网内的高价带宽，比如说视频网站里面的部分冷门视频等等——点播视频这种东西，对延迟和丢包敏感度并不是那么高，只要不是丢包太严重，只要视频能正常加载（尤其是目前各大厂都在压缩视频码率的情况下），相对较低质量但也较低价格的跨网带宽，还是会受到欢迎的。

这种做法，因为明面上的网间结算费已经消失了，御三家在明面上都不好说什么，但客观问题不会因此而消失。这次则是三网互联的链路容量问题占了上风，当然还会外带一些上面括号里面提到的，省公司私底下的结算费问题。换句话说，我们目前面对的是链路容量不足+运营商升级意愿不足+家宽本身的低QoS等级，于是跨网拥堵就出现了。

跨网拥堵的另外一个受害者，自然就是科学上网领域。曾几何时，广移拉AZ，AZ拉万物，是很多玩这个的口头禅，虽然可以拉万物的不仅仅他一家，但因为移动的CMI带宽便宜，AZ正价贵但可以用月抛，更不论一大批如PCCW之类的低价国际带宽，两者对接简直王炸。

但跨网拥堵出现之后，就出现了两个很好玩的情况。

先说第一个。部分海外机器是没有所谓的大陆优化带宽的，也就是说如果一般情况下路由都需要绕美，但一个很好玩的例外就是移动的CMI，因为价格便宜，很多线路还是会顺便拉一条CMI的（有传闻称此种做法占比不低），典型如JMS的HK CMI套餐，目前的线路是大陆方向三网回程均为CMI（之前移动CMI，别的走NTT）。请注意，CMI是移动海外段，所以大陆的不论什么运营商，想访问CMI，必须经过9808，也就是移动骨干网。喏，在跨网拥堵的加持下，其他两家用户的丝滑体验就这么消失了，大家一起挤跨网通道去呗。

第二个结论，笔者想了想，决定单独开一小节。

2.0.3 跨境拥堵

从上面的叙述不难得出结论：自从出现了跨省结算之后，我们可以认为，运营商开始了疯狂的QoS，只要是晚高峰时间段，跨省，跨网，跨境，都会被分三六九等的QoS，如果你等级低，那就到一边排队去吧——于是就形成了拥堵。

于是在低QoS等级的线路，比如家宽，即使远端服务器接入了CMI，移动也会变成移不动。表现形式通常是日间还算好，一旦进入晚高峰时段，就会出现高丢包高延迟高抖动的情况，或者虽然ICMP测试良好，但因间歇性丢包导致队头阻塞问题，实际跑服务会发现视频看一秒卡三秒。

晚间，实测，丢包率普遍在20-30%

高QoS等级的线路，例如流量卡，例如专线，情况则会好一些。前段时间广东移动推出过一款专线SKU，不知道现在是否还有售，其交付形式为：两条PON链路，一条为带宽较小的专线（例如100下10上），另一条为带宽较大的所谓商务宽带（例如1000下50上，本质上就是家宽），无需营业执照，价格也相对较为便宜，最低的只需百来块钱，和电信家宽差不了多少。虽然这种『专线』自然是比不上真正意义上的专线，比如SDH电路和PTN电路，但俗话说得好，瘦死的骆驼比马大。虽然这根专线在网内也是走的9808，但至少与配套的家宽相比，在两方面上可以看出有不同：

• 地址分配：以广东为例，家宽可能会分配120打头的IPv4，2409:8a打头的IPv6；这根专线，则可以拿到123开头的IPv4，以及2409:87开头的IPv6（且多为静态v6）。IPv4的情况笔者并不清楚，但v6，根据网上的资料来看，a代表『家庭宽带用户』，7代表『集客专线用户』，很显然有所不同.
• QoS等级不同：此点并没有确凿的证据，但根据办理了此业务的群友反馈，在晚高峰时间段，通过专线访问香港CMI网络，效果显然比家宽要来得好，至少丢包率会低很多，让TCP有充分能力把速度跑起来。

于是这就引出了一个很好玩的猜想：9808，或者说其他两家运营商的骨干网都好，其实一直都那样，只不过以前大家都是60分的成绩（或者说至少没差那么远），现在通过更加疯狂的QoS，让家宽继续下跌到40分甚至30分，而专线还能有60-80分。此时我们作为家宽用户，自然是感觉到上网质量变差了。

关于这个问题的解决方案，实际上也是存在的，但大多数都可以归结为世界加钱可及。这一部分内容在下面的2.4小节还会继续讨论，但现状就是，笔者跟人打趣说：以前打电话要交长途费，现在上网也要交长途费（专线带宽）了，而且如果你并没有觉得自己的宽带费用有所上涨，那么显然，你已经成为了垫脚石。

那么，觉得花钱太贵的话，有没有『穷开心』的方法呢？笔者将在2.3节继续讨论此话题，在此之前，我们先看看互联网上的一些遗迹，看看老前辈们在过去的日子里是如何解决类似问题的。

2.1 上海站 vs 广州站

经历过拨号上网年代的朋友可能还记得，早年间的门户网站，比如网易，新浪等，会在页面上列出『广东分站』，『上海分站』等选项，供访客选择：

2003-03-29 新浪首页

虽然到后期，这些选项更多地变成了『展示地方特色新闻』等用途，但互联网在神州大地上刚刚起步的时候，也就是上世纪末，这些地方站确实是会对应不同地区的服务器的，比如你点击上海站，就跳转到上海服务器。各站点之间数据不一定能及时同步，比如发帖，可能要等几个小时甚至一天时间，才会出现在其他服务器上。出现这样的现象，其实和早期互联网接入速度慢有很大的关系，带宽不能满足网民需求，也无法满足服务器互联的需求，只能通过这样的方式，来分散链路压力，其实也就是早期形式的CDN了。

无独有偶，这个现象在各大软件下载站其实延续了很久。以前的软件下载站是真的会自己去买带宽来分发软件的，而因为软件包体积较大，早年间跨网性能同样无法满足需求，因此很常见地，会在下载站里面看到各类下载地址，其实指向的就是不同的下载服务器。

找不到以前的截图了，手搓了一个

2026年的今天，虽然三大流氓的跨网性能有所改善，因此很多情况下随便点一个都能成功下载。但，抛开上面提到的跨网拥堵不说，就算不拥堵，网内带宽通常也比跨网带宽要大，所以正经一点的下载服务依然需要靠网内CDN来实现高速分发（例如Steam）。不过他们已经可以通过各种方式，例如DNS智能解析，例如自己的API，来判断速度最快的CDN地址，不再需要用户自行选择了，年轻一代对于『下软件要选线路』这种事情也逐渐变得陌生。

2.2 酸溜溜地卡成狗

互联网冲浪时间足够久，什么经历都有可能出现，当然笔者没有。不过根据过来人所说，13年，SS横空出世的时候，一众GoAgent/SSH用户纷纷觉得，SS这玩意惊为天人，相比以前的工具，体验真的丝滑了很多。尤其是，那个年代很多（尤其是低价的）VPS使用OpenVZ虚拟化，是共享主机内核的，如果商家没有给宿主机开TUN权限，需要创建虚拟网卡的VPN类程序就无法使用，你还得火急火燎地找商家开，商家还不一定愿意开。SS作为一个代理程序，不涉及到TUN，自然也不需要这么麻烦了。

不过很快人们就发现，想要维持一条快速的越洋链路似乎并没有那么容易。那个时候，网上视频已经比较发达了，但是真正到油管看视频，加载速度却总是慢得令人难以忍受，家庭宽带接入已经迈入8M、10M甚至20M和50M的时候，油管视频加载速度却只有几百Kbps，完全无法满足当时正在兴起的1080P甚至4K流媒体的需求。

从上帝视角来看，出现这样的情况，其实有很多个维度：

• 跨境拥堵：当年的拥堵还是很纯粹的，出口总带宽不足，使用的人又多，那确实会拥堵，这是物理定律和客观条件的限制。
• 运营商QoS：当年的运营商下三滥手段其实和现在相比有过之而无不及，HTTP是明文传输，在网页里插广告已经是基操，更有甚者是广告里插网页（也就是在广告页面中间放<iframe>，嵌入目标网站）。和这个话题相关的是，运营商会对非80/443（或者非HTTP）的流量进行限制，表现起来就是，非标端口和非标流量，速度比访问正常网页要慢。
• 远端带宽不足：经常能看到某商家在MJJ口里变成了『超售王』，意思就是此商家为了多卖钱，在一台宿主机上开出了超过其承载能力的虚拟机——在OpenVZ虚拟化的年代尤其猖獗，因为OpenVZ超售简直易如反掌，甚至有部分机器因超售到内存严重不足，虚拟机开都开不起来。但即便如此，这类机器因为价格便宜，多为One-man供应商，不必像大供应商那样要求掏出来一张外币信用卡才能设立账户以及付款，所以还是有很多人去购买的。不过事实就是事实，机器超售就意味着资源不够分，其中自然也就包括了带宽资源：不妨想象一下，一台宿主机上挤了成百上千台OpenVZ草履虫，大家都来抢带宽，是个啥样。
• LFN与高丢包：老生常谈的话题了。在那个没有BBR的年代，LFN与高丢包的阴影挥之不去。

最后一点，是我们的重点，因此下面我们会详细谈。

我们都知道，17年左右谷歌推出了BBR，但是在BBR之前的几年时间里，我们用的加速技术就五花八门了，比如FinalSpeed，比如锐速，以及我们今天的主角，KCP。

2.3 狂奔的 KCP

在讨论本节之前，先来个小定义：因为笔者的一些奇怪的小习惯，因此如果你在下文看到『TCP包』之类的表述，准确来说，指的都是TCP Segment。

当年折腾过SS的朋友，应该或多或少听说过KCP的大名：

KCP其实上得了台面，比如原神就在用KCP

当时有不少博客文章都提到，KCP可以提速100倍。准确来说，是给的SS套上KCPTun（KCP协议的一个实现，增加了外围配套代码）之后，油管加载速度从100Kbps提速到10Mbps，刚好100倍，原本看360P都费劲的线路，现在1080P都可以随点随看，体验是直线上升的。而且KCP最大的好处在于，他也不依赖内核态的程序，因此在锐速和BBR都用不了的VPS上，也能发挥加速效果。因而那时候，KCP几乎是每个自建玩家的标配，甚至到了后来的*ray年代，软件也依然有对KCP的支持（当然，实际实现是mKCP，有所改进，与KCPTun不兼容）。

为什么KCP和FinalSpeed之类的程序，可以给线路加速？其实道理很简单，他们本质上是基于UDP，自己重新实现了一个可靠传输层，规避掉了TCP的一些问题——正因为如此，我们有时候也会称呼这类协议为UDP-Based协议（注意此处不要与UDT协议混淆），两端的TCP代理程序不再维持一条跨洋的TCP连接，而是通过加速软件提供的UDP-Based传输层桥接在了一起。

2.3.1 TCP的包袱

如果想要详细解释加速原理，还得结合LFN（长肥网络）+队头阻塞+丢包重传这三个难兄难弟来讲。再次提醒，笔者不是TCP专家，因此下面内容讲得比较粗略，只是简单介绍这种现象的起因而已，有需要的朋友可以自行参考相关资料。

先简要介绍何为LFN。根据RFC 1072的定义：把带宽（单位bit/s）乘上链路RTT（往返延迟，单位为秒）称作BDP（带宽延迟积），如果BDP大于100000Bit，就认为此链路是LFN。举个例子，比如我们从中国到美国，有一条10Mbps链路，RTT是150ms（已经算很好的了），那么计算可知，(10*1024*1024) * 0.15 = 1572864，显然大于10万，因此这就可以被认为是LFN。

我们都知道，TCP作为一个可靠传输协议，原因之一就是他会通过ACK包来确认数据是否到达。一般来说，TCP发一组数据之后，停下来等等，等到收到对端发来的ACK包，知道对端已经把某段数据收齐，才会继续发送剩下的数据。如果数据发出后，一段时间内没有收到对方发来的ACK，就认为链路丢包（要么是丢数据，要么是丢ACK，总之就是丢了），会重传刚才发过的数据。显然，这么干虽然可以确保数据不丢，但一旦链路延迟加大，那么『等ACK』这个操作的时间占比也会加大。

此外还有一个问题：因为不可能说『发一个包收一次ACK』，那样效率太低了，所以TCP当中有一个cwnd（拥塞窗口）参数，他是决定发送方单次（收到ACK之前）能发送多少数据的参数之一。这个值不是固定不变的，在连接刚建立的之后有一个初始值，然后收到一次ACK就增长一次（俗称加窗），直到大于ssthres（慢启动阈值），然后就交给拥塞算法来处理。又因为TCP的带宽可以使用cwnd / RTT来近似计算，所以我们可以观察到TCP刚建立连接时速度较慢，但随着加窗的进行，用着用着就变快了。

显然，如果在LFN上，因为RTT较高，要想达到合适的速度，cwnd也要加得很大，但此时加窗也相对较慢，而且加窗一次能带来的速度提升也不多，一根筋两头堵，最终表现出来就是速度增长很慢，这就是我们说的，TCP在设计之初并没有针对高延迟链路做优化。

此外，这还只是理想情况。在TCP被设计出来的那个年代，受限于当时的网络环境，传统拥塞算法的开发者可以安全地假设『如果链路丢包，说明链路拥堵』。既然拥堵了，那么就要减慢发送速度，避免加剧拥堵情况。传统拥塞算法（例如Reno）一般会在碰到丢包时把cwnd减半，来限制发送速度。但问题是，实际情况下，LFN总是伴随着高丢包出现，比如无线网络，比如上面提到的中美链路，此时的丢包并不意味着链路一定就发生了拥堵，上面的假设不一定成立。结合上一点来看，LFN网络中合适的cwnd值本来就很大，但只需略微丢包，就会导致cwnd对半砍，发送速度大幅降低，要想回到原来的合适值，就需要花费数个甚至数十个RTT重新慢慢加窗。如果加窗加到一半又丢包了，对不起，请大侠重新来过。

所以在多重因素交织之下，TCP在LFN中的性能也就难以得到提升了。

2.3.2 KCP的另辟蹊径

KCP提高链路利用率的具体方法，在项目主页已经有所介绍，而且也有很多博主介绍过，这里不再班门弄斧了。而且严格来说，KCP是多管齐下解决问题的，因此本文无法全部覆盖。

但可以确定的一件事是，和传统的TCP拥塞算法不同，KCP对高丢包链路有针对性优化（毕竟是一个新近的协议），不再把丢包视作链路拥堵的信号。如果碰到丢包，那么补发就行，而且补发也不是像TCP那样重传一大段，他可以计算出来到底丢了哪些包，然后有选择性地重传（和TCP SACK类似）。此外，KCP的发包机制不再受限于对端的ACK，而是使用时间驱动，减少了链路RTT所带来的影响，这也是提高链路利用率的做法。结合这些优化措施，才有了KCP的『提速100倍』的神话。

但也正因为这些原因，类似KCP和FinalSpeed这样牺牲链路公平性的拥塞控制协议，包括用于改进TCP的BBR，被部分研究者认为是『不道德』的协议，因为这些新协议可以认为是在抢占带宽，挤压了传统的拥塞控制协议可用的带宽空间，因此不适合大规模部署/推广使用。

光从这件事上来看，其实双方好像都说得过去，开发协议的人想让速度更快，反对的研究者想让链路更加公平而不是一人吃独食。笔者也不好说到底哪一方比较合适，但从客观事实上来说，目前的现状就是，讲道德吃不饱饭。甚至在这一刻，受限于晚高峰以及跨境拥堵，笔者后台也必须挂着另一个基于UDP的传输协议Hysteria2，才能流畅地更新文章，不然就和以前的拨号网络一样，出现网页加载一半，后面还没出来的情况：

新鲜的例子

2.3.3 UDP 是未来？

谈到UDP，一般认为运营商对它没什么好脸色，因为它太灵活了，基本上可以认为就是『带一个端口号的IP数据包』，可以玩各种花活，所以有了上面提到的各类新协议，但也因他很难控制，所以只能对UDP流量一刀切，甚至有小ISP直接阻断UDP包的情况。

但如今，业界开始逐渐重视起UDP来，除了他灵活之外，更加重要的一点可能还是UDP相对来说已经是被广泛接受的那个了。我们都知道，OSI模型的第四层是传输层，典型包括TCP和UDP，但实际上同属此层的还有很多，比如说SCTP和DCCP，你可能没有听说过这俩玩意，那就对了，因为其他的传输层协议在互联网上的利用率就非常低，甚至DCCP已经因缺乏维护而在Linux Kernel 6.16版本中被移除了。就算不移除，且双端都支持使用这些协议，在链路上的某些设备，比如NAT和防火墙，可能也会因为不认识这些协议而阻断/无法处理。

显然，增加新的传输层协议，意味着要修改全球所有的NAT和防火墙的代码来支持新协议，这显然不可能，所以TCP和UDP已经成为了事实上的标准。而TCP又已经固化于全球绝大多数设备的内核代码里面，同时也因为TCP元数据是明文的，会有数不清的中间设备会修改TCP元数据，所以同样很难整什么新花活（即所谓的『协议僵化』），摆在程序员面前就只剩下UDP，这个几乎撒手不管的传输层协议。近来最典型的例子便是QUIC，同样是基于UDP的可靠传输协议，主要目标之一就是解决之前的博文提到的队头阻塞问题：基于UDP的特性，应用层可以不再受限于内核层，自己使用更合适的流控协议来发起多个逻辑流，避免了一条流阻塞导致其他流跟着阻塞。

至于UDP会不会成为新的未来，目前还很难说，因为虽然UDP-Based协议可以根据需要采用更加符合现状的流控策略，但还是那句话：TCP的统治地位已经根深蒂固了，短期内很难全部改变；TCP虽然协议固定，但也因此可以开发合适的硬件加速策略，例如TCP Offload，这一点，灵活多变的UDP可能较难实现；运营商对UDP也没有什么好脸色，导致UDP-Based协议需要更激进的重传和拥塞控制策略，可能导致运营商脸色更差，导致策略更激进...于是又是一个恶性循环。

也许到最后，可能和现在的IPv4与IPv6差不多，大家都认为新来者可以取代旧日的霸主，但实际上也只是共存而已。

2.4 世界加钱可及

双管齐下从来都是有用的，不论你是在调AB胶，还是在修网络。

世界加钱可及这个说法，具体出处已经不可考了，只知道很多情况下是用来形容电信的（因电信的宣传语就是『世界触手可及』）。然而对于我们今天的讨论来说，显然也不仅仅限于电信，而是御三家都适用的，需要花钱才能办到的加速技巧——毕竟从本质上来说，我们碰到的拥堵与丢包，其实是有限的链路资源在不均匀分配下所导致的结果。这当然是合理的，毕竟这是商业行为，每个月交10块钱和交10万块钱，能买到的东西当然不一样。

和上面换协议所带来的加速效果不同，增加（正确的）付费量，提高的是另一个层面上的质量：如果说使用UDP-Based加速协议是让你在公路上和其他车辆竞争时更有优势，那么正确的付费，可以让你走高速甚至高铁，不用再挤公路了。

2.4.1 服务器影分身

前面提到，我们的问题是跨网拥堵和跨省拥堵，从直觉上来看，最简单的解决方式就是让资源既不跨网也不跨省，让不同地域的用户访问到不同的，但都位于网内的资源，这样才能加速。这听起来像是一句废话，但别忘了，很多商业服务根本没有那么多空间进行奇技淫巧的优化，只能从根源上来解决问题，所以这一点其实是首要思路之一。

打开B站挑个视频，右键查看视频统计信息，可以看到加载视频和音频的CDN域名。如果你不是在什么偏远地区，大概率可以看到域名里包含的地区，就是你省内的某个地区：

BV1rx411c7BP，深圳的两个对象存储

例如上图，我们可以拿着这两个域名去做DNS查询（查询AAAA结果，这是有意为之的）：

# dig upos-sz-estgoss.bilivideo.com aaaa +short
uposmirror.oss-enet-ds.aliyuncs.com.
uposmirror.line-isp-province.oss-enet-ds.aliyuncs.com.gds.alibabadns.com.
2409:8c04:****:****::****
# ...后略

# dig upos-sz-estghw.bilivideo.com aaaa +short
upos-sz-estghw.bilivideo.com.0e471ad9.cdnhwcggk22.com.
bili.cold.v6.d.cdn.chinamobile.com.
2409:8087:****:****::****
# ...后略

显然，由于笔者点开的是某个冷门视频，程序选择从对象存储加载（如果是热门视频，可以直接从热门缓存CDN拿，域名中一般带有mirror字样），且从CNAME解析可以知道，前者是阿里云的对象存储，后者是华为云的对象存储。

现在，查询AAAA的好处就展示出来了。熟悉IPv6的读者可能已经看到，因笔者家里是移动的宽带，所以在DNS智能解析的帮助下，这两个域名的解析结果，均返回了属于移动的IP段（2409:8000::/20），再加上两个节点均位于深圳机房，于是这就实现了流量既不跨省也不跨网。

此外，多说一句，如果我们按字符串来算，前面的地址第二段第二位为c，而后面地址第二段第二位为0，根据V2EX的这个帖子以及询问友人的情况来看，前者对应的是第三方自建机房（本例中为阿里云），后者对应的是移动自己的机房。这其中的质量区别笔者并不清楚，可能后者比前者优先级高，也可能区别不大，谁知道呢。

想要不跨省，简单，把机房放在省内，一般都能满足需求。至于想要不跨网，本质上是要让机房在网内可达，而不必借道另一个运营商。要实现这样的效果，理论上来说，可以使用BGP，把云厂商自己的IP段在三大运营商网内都做宣告，让内部都有最优路由，来实现流量自动选路。但毕竟之前也吐槽过，国内（大陆地区，下同）BGP的价格可不仅仅是一个『高昂』了事，对于OSS/CDN这类大带宽业务，在国内如果全用BGP，云厂商得亏死。

由于此类SaaS服务是通过域名访问的，所以正如上面的解析结果可见，云厂商选择了『三线接入+DNS分流』的方式，对于同一个OSS/CDN域名，不同运营商的用户在查询DNS时，DNS可以根据用户源IP来返回最优的机房地址，电信用户就给电信IP，移动用户就给移动IP，成本比BGP低很多，大家也都不需要跨网了，皆大欢喜。

2.4.2 两头有专线

2.0.3 节提到过，高QoS等级的线路，例如流量卡，PTN接入，甚至所谓的『PON专线』，即使使用同一条路由，其效果也会相对较好——毕竟是充了会员的，当然要优先服务。

其实不仅仅用户侧如此，服务侧也差不多。比如说，笔者目前用来托管本站点的美国VPS，在晚高峰时期的延迟和丢包率，可以说是惨不忍睹：

# ping 2607:****::****
PING 2607:****::**** 56 data bytes
64 bytes from 2607:****::****: icmp_seq=1 ttl=.. time=288 ms
64 bytes from 2607:****::****: icmp_seq=2 ttl=.. time=288 ms
64 bytes from 2607:****::****: icmp_seq=3 ttl=.. time=288 ms
# 4号包丢失
64 bytes from 2607:****::****: icmp_seq=5 ttl=.. time=288 ms
.....

然后，我们随便找一家出售高端线路的商家，打开他的Looking Glass页面，挑一台优质美国线路的机器来看看：

# ping 2605:****::****
PING 2605:****::**** 56 data bytes
64 bytes from 2605:****::****: icmp_seq=1 ttl=.. time=172 ms
64 bytes from 2605:****::****: icmp_seq=2 ttl=.. time=172 ms
64 bytes from 2605:****::****: icmp_seq=3 ttl=.. time=172 ms
64 bytes from 2605:****::****: icmp_seq=4 ttl=.. time=172 ms
64 bytes from 2605:****::****: icmp_seq=5 ttl=.. time=172 ms

没有丢包，延迟更低，当然价格也更加美丽。一分钱一分货的道理，在这里得到了完美的体现。这还只是美国的结果，如果换成香港VPS，因为存在低价VPS因没有购买直连带宽而引发的绕美问题，差距会更大：

# 这是某高端品牌的优质网络香港VPS
PING 2403:****::**** 56 data bytes
64 bytes from 2403:****::****: icmp_seq=1 ttl=.. time=23.4 ms
64 bytes from 2403:****::****: icmp_seq=2 ttl=.. time=23.3 ms
64 bytes from 2403:****::****: icmp_seq=3 ttl=.. time=23.3 ms

# 这是笔者手头的便宜香港VPS
PING 2602:****::**** 56 data bytes
64 bytes from 2602:****::****: icmp_seq=1 ttl=.. time=463 ms
# 2号包丢失
64 bytes from 2602:****::****: icmp_seq=3 ttl=.. time=441 ms

所以你会看到，很多建网站的朋友，会花大价钱去购买优化线路的VPS，因为带来的效果可不仅仅是打开网站能不能快两秒的区别，直接就是打得开与打不开（超时断开）的区别了。

2.4.3 多线入户

还有一个玩法就是，资源不动，你来跨网。虽然说是家宽，但是部分技术用户也会给家里拉上不同运营商的宽带，比如移动+联通之类的，然后按需分流，让自己主动地用不同线路到目标网站上去访问内容，通常是访问跨境的机器，因为很多海外VPS在不同运营商的网络下访问的效果是不同的，家里多线接入的情况下就可以挑一条好线路去使用了。

这种做法其实并不新鲜，只是因为办理手续较为麻烦，且一般人没有那么高需求，且毕竟也是额外开销，因而显得少见。比较多见的地方是网吧，比如说划分不同区域的，游戏区就给你拉质量高一些的专线，确保游戏连接不抖动延迟低，普通区就用价钱便宜的普通宽带（甚至家宽聚合，早年间甚至是长城宽带），能满足影音之类的需求就可以了。这种分法不需要什么太高级的路由器，只需要分开拉线即可。当然也有厂商会出售网吧路由器，你付费之后可以获得分流域名/IP库的访问权，于是就不用特地分区了，大家连上来就可以各取所需。

前台路由器的诱惑力挺强的（手动滑稽）

所以在今天的跨网拥堵情况下，最优解反而可能成了部分地区的广电网络和部分高校的校园网（当然前提是上联口不卡顿），因为他们可能真的会根据用户访问的IP段去分流，让来自不同运营商的上联口能均匀获得流量。

2.4.4 香肠的切割方法

早年间，如果碰到出海不畅的问题，到各大论坛去询问，得到的回复通常都是，『去买台中转机，中转一下吧』。人们给出来的解释是，中转机有较好的网络性能，你家宽带可以顺畅地连接到中转机，中转机又可以更顺畅地连接到目标服务器，于是整条链路就畅通了。

这当然是对的，也是合理的。但假设你突发脑洞：目标服务器在美国，虽然说是直连，但速度也很慢，现在你租用了一台位于新加坡的VPS，作为中转机，让整条链路变成『你家——新加坡——美国』。按理来说，海外的中转机用处不会太大，但实际测试发现，连接的速度也会有所提升，网络也会更稳定，这是怎么回事呢？

首先我们需要了解常见用户态中转程序，比如gost，realm，echo，socat（但并不包括基于DNAT/SNAT的iptables）他们的工作原理：客户端连接到转发程序，转发程序连接到目标服务器，工作时，转发程序从一条TCP连接中把数据提出来，再放入另一条连接中发送出去，反之亦然。

显然，使用此类中转程序时，出现了两条TCP连接，也就是说完整的四层链路在中间被断开了。我们在2.3.1节讨论过有关LFN的话题，当时为了简便起见，没有提及的一点是，RTT的计算范围仅限于完整的一条TCP连接内。还是回到我们刚刚的例子，从家里连接到美国，假设往返延迟是180ms，那么RTT就是180ms。但由于中转程序的存在，连接到新加坡，假设延迟70ms，新加坡再连接到美国，假设延迟80ms，那么他们的RTT就不能用70加80来计算，应该视作两条连接，分别来看。

很显然，此时连接被一分二，单独连接的RTT都不高，缓解了上面提到的LFN中的问题。

这样的方法在很多工程案例中都有用到，尤其是对抖动比较敏感的游戏加速器，从出海点出来之后，可能并不会直连目标服务器，而是先连接到目标附近的另一台中转服务器，再连到目标。虽然说这么干一般情况下并不主要是为了降低TCP RTT问题，更多的是缓解路由绕路问题（毕竟当两头都是自己人的时候，中间就可以按需优化了）。

除了游戏加速器，还有另一个会用到此种方法的，那就是我们下一大节的重点：SD-WAN。

3. SD-WAN 的世界？

SD-WAN是近几年的大红人，仿佛有了这玩意，什么网络问题都能迎刃而解。

可是，当真如此么？

3.1 你的名字？

上帝啊，如来佛祖啊，太上老君啊，岩王帝君啊，这SD-WAN到底是什么？

图源Cloudflare介绍SD-WAN的页面

我真的很想骂人，关于这个话题，我在互联网上已经查询了几年时间，但是没有一篇文章告诉我这SD-WAN到底是何方神圣。点开文章，里面只会告诉你一句，『这是基于SDN的技术，能加速网络连接，混合网络，应用级细粒度QoS，可以使用多种硬件』，等等等等一大堆优点，顺便还会给你补一张花里胡哨不知所云的拓扑图。如果你继续问，他还会继续扔出来几个技术名词，还会告诉你『SD-WAN主要部件有SD-WAN控制器，SD-WAN网关』，还能蹦几个英文缩写出来，什么vCPE，uCPE，CPE，PE，最后还会告诉你，我们家的SD-WAN很牛逼，快来买啊。可是，直到你看晕了，都还没搞明白SD-WAN到底是什么。

我就这么跟你说吧：路由器晓得不？对，就你家那个路由器，上面是不是有一个Web管理界面？把路由器劈开两部分，一部分是负责管理和控制的，叫他控制器；一部分是负责流量转发的，叫他转发器。现在把一大堆位于不同地理位置的路由器的控制器都变成统一的一个，放到某个地方，让这一个控制器可以管理手下的一群转发器。管理起来之后呢，这群转发器就可以听控制器的话，选择合适的方式互联起来，这就是SD-WAN。

没错，就这么简单。

说白了，不论你认知中的SD-WAN有什么高级功能，比如组网，跨境组网，加密互联，多路径连接，全网状连接，链路自动倒换，L7（应用层）级别流量感知与分流，策略集中下发，零配置上线，等等等等，都是基于上面那段文字实现的。举个例子，比如说组网功能，现在控制器告诉你，有这些这些站点，地址是多少多少，密钥是多少多少，你去连接吧。你收到这条消息之后，按指令连接各个站点，这不就是组网？

长期以来，SD-WAN，可以认为是被各大厂家和商业组织刻意做成了一个宽泛的，用来描述某一类解决方案的名词。其中的一个重要原因是，从技术角度看，SD-WAN没有任何定义，也并没有像我们认知中的那些『正经』协议那样，具有什么标准文件。我们看到IPSec知道要去找RFC 6071，看到VxLAN知道要去找RFC7348，但是看到SD-WAN就不知道要找什么了，就是因为他并没有一个硬性标准，只有一个大致的概念。换句话说，SD-WAN更接近于包装纸，里面包着的是『参考的架构』与『具备的能力』的集合体，厂家只要实现了这些能力，不管你怎么实现的，只要有对应功能，就可以称自己的产品为SD-WAN了。

也正因为此，不同厂家的SD-WAN，除了基础概念和功能外，很难说有什么技术上的共性，甚至具体的能力，如设备情况，链路监控能力，流量感知能力，组网能力，差异可能也是巨大的。网上看到SD-WAN会混合采用互联网/MPLS专线/4G/5G等接入方式，结果你选购所谓SD-WAN之后，厂家发过来一个小盒子，让你插原来的路由器上就完事了，也是正常现象。

从商业的角度看，厂商写介绍SD-WAN好处的文章大多数都是为了营销，说人话就是打广告，如果厂商写太详细，那么这文章也不再适合做营销了，只能写一写『智能调度』、『云原生』、『合规跨境出口』之类的营销词汇，就跟当年的『大数据』、『互联网+』一样，不能说他假，只能说是宽泛地描述了功能，你碰不到技术细节罢了。而且说实话，一方面是这些宽泛的名词可以帮厂家拓展市场，另一方面是客户也不在乎技术细节，尤其是对于搞TikTok直播的跨境电商等非技术型用户，只要能用，好用，可以满足技术和预算需求，那么不论你叫SD-WAN还是veRyaWeS0me-LiNe，客户都会买账。

厂商的文章不是好的研究来源，又没有相关标准，于是对SD-WAN的理解，就长期处于没有准确定义的不明就里状态了。所以，为了契合本文主题起见，也为了方便我们接下来的讨论，这里只研究两种相对有一些技术共性的SD-WAN：

• 组网产品：用各种方式组隧道，让各种设备可以接入同一张逻辑内网
• 跨境产品：也就是『有信通院认证』的厂家推出的，用于跨境电商等合规用途的跨境上网产品

截图取指中国移动手机APP的政企服务专区

3.2 专线共享贵宾室

SD-WAN在很多营销文章中都会提到『降低成本』一词，其实他降本的原因很简单：更精细化地控制流量，避免无谓的额外开支。

在继续接下来的话题之前，有必要提醒一句：下面的内容几乎就是各大SD-WAN厂商竞争力的核心，说白了就是属于商业秘密，像这样能帮他们一个月月入六七位数的技术，根本不可能被笔者用一个问号问走（如果可以的话，我也不用在这里写什么博客了，赶紧去挣钱啊）。因此下面的内容更多的只是根据公开资料所推测出来的，如有不准确之处，望见谅。

3.2.1 矛盾调停人

我们先来考虑这么一个场景：某企业有两个分公司，比方说一个在上海一个在广州，现在为了办公需要，他们的内网需要连接在一起，以便双方都能访问到某些特定的内网资源。

显然，这个场景非常典型，网络专业的大学生，以及实际干网工的朋友，都或多或少听说过类似的玩意。对于传统的企业来说，常见的选择主要有两种，一个是物理专线（现在多用MPLS），一个是用互联网跑VPN。当然如果你不嫌弃的话，也可以两端各配一个拨号猫，通过PSTN拨号的方式建立PPP电路，享受一下扣掉传输层开销后只剩下4.5KB/s的感觉——但我相信，在2026年的今天，除非迫不得已，应该没人会喜欢这么干。

显然，前者适合高稳定性，独享带宽，高可用性，低抖动....反正就是一大堆高SLA需求的场合，只要你出得起钱，那么专线的使用体验是很好的——但问题就在这：物理专线的价格是很高的，至少比普通的上网线路要高，一般公司未必撑得起大带宽专线的开支。况且，就算资金不成问题，物理专线的开通也是需要时间的，包括等资质审批，等施工放线，等运营商开通路由，都得花时间，虽然说就整个企业的生命周期而言，这点时间不算什么，但他的灵活性总归来说不算太好。

另一方面，用互联网跑VPN，这个是近年来部分企业的主要选择，甚至唯一选择（比如给出差员工使用，总不可能随身带根专线到处跑吧）。VPN和专线就刚刚好反过来，优点是带宽可以较大，开通快捷，部署简单，价格也很低廉；缺点自然就是没有SLA保证，延迟抖动都无法避免，你的数据包在公网上说没就没，说绕路就绕路，不适合有高稳定性高安全性要求（如金融）的业务。

而SD-WAN，其实想要解决的就是这两个矛盾，很多厂商所宣传的『多路径混合接入』以及『应用流量感知』就体现在这里：比如上面那个企业，要求有100M的跨地域内网带宽，如果你开100M MPLS，价格太贵，开VPN，稳定性不够。但其实仔细想想，所有应用都得具备一模一样的优先级吗？比方说：

• 文件传输，需求可以略低
• 视频会议，那么最好不要卡顿
• 合同和营业数据的传输，安全性应该排第一
• 内线SIP电话，流量优先级排最高

那么，企业就可以选购一根10M的MPLS专线，搭配90M的VPN，两头同时插SD-WAN设备上，设备会自动感知到当前正在跑的是什么流量，就可以按需分流。还是上面的例子，检测到SIP电话就往MPLS分，检测到文件传输就往VPN分。像这样混合接入，原本没必要跑在MPLS专线里头的流量就可以剥离开来，专线的需求降低，企业就可以省下这部分的专线开支，成本会低很多。

3.2.2 你的专线在云端

有读者要问了，那你讲了这么多，和我们本文的跨网主题有什么关系呢？然后又有另一部分读者要问了，我买了这种SD-WAN，连接质量确实好，但我也没看见有什么专线连到我公司里头啊，就一个小盒子插宽带上而已。

本节主要就是回答这两个问题的。

上面我们提到，SD-WAN并没有严格定义，因此有部分厂家嗅到了商机，他们做了这么一些事情：

1. 在多个地方，建立接入了不同运营商的大带宽PoP点（Point of Presence，入网点）
2. PoP点之间，由厂家使用各种方式连接在一起，形成Overlay网络，并统一调度
3. 出售产品时，厂家给你寄的小盒子，就会通过互联网就近连接到网内的PoP点
4. 业务数据在PoP点之间高质量传输

某著名跨境SD-WAN公司所提供的PoP点列表

目前很多组网SD-WAN和跨境互联网SD-WAN，尤其是SaaS型SD-WAN（软件即服务，就是给你一个SD-WAN软件安装到终端上的），都是基于这样的架构来做的，毕竟这也是平衡服务成本和服务质量的一个好方法。

这个结论也并非空穴来风：

首先，显然，对于一般用户来说，他能接触到的『网络』就是互联网。3.2.1小节中举的例子里，使用SD-WAN的企业还要自行置办小带宽MPLS线路，但问题在于，专线带宽所带来的边际成本其实并不大，虽然小带宽线路确实比大带宽的要省钱，但资质审批和施工放线等麻烦事一件也不少，而且麻烦程度并不相上下。企业内网数据的价值是否值得付出这些麻烦的代价，就是一个很值得商榷的问题了——这个问题的答案，在很多情况下可能都是『否』。

所以SD-WAN厂商在这里扮演的就是代理商的角色：他是专业做网络的，自然有资质，有技术去置办此类专线，而且还知道怎么把专线连接到自己的PoP点，怎么调优，甚至可能直接和运营商合作，比如拿一个大批量优惠价什么的。此外，上面提到各PoP点的连接方式可以是多种多样的，除了可以因地制宜租用各种专线之外，还可以使用经过调优的价格相对低廉的公网，来跑重要性比较低的业务。这里举一个不太相关的例子：前两年有一个不作死就不会死的机场老板，宣称自己出售的是『高端品质，中端价格』，后来爆雷之后，大家都知道了他采用的技术，无非就是公网+略好一些的线路+MPTCP而已，但却实打实的帮他降低了成本。

IPLC也是一种专线类型

各种连接资源进入PoP点之后，厂家就把他们抽象为资源池，内部用各种技术划分为多个逻辑通道（相当于多个用户合租了一根专线），就可以按需出售了。因为这些PoP点本来就接入了不同的运营商，因此和上面2.4.1小节提到的一样，会给用户分配不同的入口地址，用户端的设备再使用传统VPN协议（或厂家自研私有协议）连入PoP点，就可以做到不跨网不跨省。

显然，现在的网络拓扑变成了：

公司A——公网VPN——厂家PoP——专线——厂家PoP——公网VPN——公司B

比全程专线要便宜，比全程VPN要稳定，厂家还帮你搞定了跨网跨省的问题，自然深得客户喜爱。现在还有部分价格相对较便宜的SD-WAN厂商会提供P2P功能，也就是让用户的各节点直接通过互联网连接起来（顺便还帮你做了NAT穿透等工作），但对于大厂商（尤其是针对大型商业用户，『价格详询』还得签合同的）来说，这种做法已经不多见，毕竟通过厂商自己的PoP来路由流量，其稳定性是可控的，是可以写入到合同里面的。

此类大型Overlay网络，个人一般难以研究，但如果你单纯只是想使用公网来玩小型Overlay，不妨看一下笔者的杏泉网络。

3.2.3 合规的跨境出口

这一小节单独把上面的类别二，也就是跨境产品抽出来聊一聊。这类产品其实并不鲜见，包括上面展示的中国移动的截图，都表示此类业务是可供办理的——价格么，一般来说相对都较为高昂（前两年接触到的报价是300-500元/Mbps/月），多少也算是一种筛选客户的软性门槛。当然，一般也都会有内置白名单与审计机制，常用的如Office365，Amazon，eBay，Zoom等会预先设置好，有别的需求再按需申请，审核后开通。

截图取自某跨境SD-WAN服务商宣传页，注意红框部分

从技术上来说，此类产品和上面那一小节讲到的，其实差别并不大，无非就是部分PoP点位于境外，他可以帮你把流量路由出去罢了。至于如何连接两个PoP点，和上面讲的一样，都属于厂家竞争力的核心，不会轻易告诉别人，不过根据笔者从多个来源（包括一位在雅思考点工作的友人）均听说过的消息来看，PoP点在实际搭建过程中，出于成本考虑，不一定全部采用专线，而是会部分采用公网，并预先申请过白目标PoP公网IP，同样可以分担专线成本。

3.3 运营商后花园

上面的内容其实都反复提到一件事，那就是PoP点到客户机房这段路，连接稳定性需求是比较高的。如果我们结合更上面一些的OSS/CDN来看，把这两件事抽出共性来做到极致，就是本小节要讨论的东西：城域网带宽。城域网在这里定义为骨干网之下，接入网之上的部分，说是运营商的后花园是一点毛病都没有的，甚至你可以把他抽象为一个大号网吧。

正如前面所说，跨网和跨省的带宽，以及IDC带宽，一般都需要上升到省骨干网级别来进行处理，而省骨干网容量一般都有限，而且此类带宽还需要保证全网可达性和高SLA需求，所以开价也通常较贵。就算你付得起，拿去用作OSS/CDN等内容分发，也可能很轻松吃掉很多容量，导致体验不算太好。

城域网就不同了，因为城域网不一定需要做域外可达性，比如我广州城域网服务好广州客户就行，不一定需要管深圳和上海的客户，再加上本来就是要建大容量城域网，除了出骨干的那部分之外，多余的带宽闲着也是闲着，因此运营商很乐意用较低的价格，把城域网带宽卖给大客户（比如云厂商），来做城域网内的内容分发，一方面可以降低骨干网压力，另一方面又能提升热门城市域内客户的体验，属实是一举两得。（不过近期有消息称运营商对此种做法有些看不惯，想要让客户多买一些价格较高的IDC带宽，因为未求证，所以看个乐就好）

对于我们的SD-WAN来说，概念也可以是一致的，因为不少大型SD-WAN厂商都有和运营商合作的意思，如果让客户优先连接到他所在城市的城域网PoP，因路程较短，延迟和抖动都能进一步降低。

3.4 襁褓中的 IXP

最后这一小节，内容不算是很多，只是略微提提罢了。

IXP，也就是互联网交换点，可以看作是一个大号的二层交换机，其作用是让各大互联网企业/运营商可以就近互联，降低互联成本，提高稳定性。之所以这个内容会出现在这里，是因为和上面的跨境SD-WAN有些关系。前段时间有个很热门的东西叫前海IX，因为在大湾区这边桥接了香港的运营商，质量也很不错，因此被不少人拿去当大带宽跨境线用（不排除有合规SD-WAN厂商接入，但很多都是黑着用）。有部分商家提供接入了前海IX的香港落地VPS，使用者需要自行购入一台大厂VPS作为前置（因为只有里面才有去前海IX的路由）。因为IXP容量较大，而且几乎就是内网直连，据说效果也不错。

不过笔者还得提醒一句，这种玩法是有风险的，虽然有消息称IXP那边对此用途心知肚明，毕竟流量方向简单审计就知道咋回事，但也有不少案例称前置机被通报，因此必须小心。

4. 写在最后

写了两万多字，后台编辑器的内存溢出问题还是有些严重，所以本文到这里就先结束了。

关于上面的内容，其实很大一部分可以看作是笔者的学习笔记，可能有理解不准确的地方，如果你有工程方面或生产环境的需要，可以查阅更加专业的资料。

（完）