更新于2025年9月5日

“为什么现在电信访问移动这么慢？”

“联通到电信是不是有QoS了，怎么才几十K的速度？”

“为什么家宽高上传会被限速？”

自2024年以来随着国内运营商开始施行网内省间流量结算以后，国内互联网的质量出现了相当的影响，从家宽高上传被限速甚至拔线，到PCDN/业务厂商跨网调度最终玩烂三家的跨网互联，导致现在梦回南电信北联通的尴尬局面，这是一个比较现实、复杂、涉及多方利益的一个问题。

本文尽可能尝试简单解释为什么会出现现在这些问题，以及从厂商和运营商角度，给读者一些不同的参考。

省流总结

现在的跨网爆炸主要是运营商利润分配、服务商成本控制等多个方面的问题导致的。运营商不希望CDN市场恶性竞争拉低营收因此选择了省间流量结算，而头部服务商为了控制流量成本又选择了便宜的带宽资源（PCDN、移动覆盖电信等做法）去跨网服务用户，在流量的累积增长之下最终导致了现在的跨网大爆炸的局面。

主要影响的是电信访问联通和移动方向，在部分省份甚至会因为运营商私下的互联结算费用，运营商不愿扩容，导致跨网质量奇差的局面（例如广东电信到广东移动）。

问题的由来

“说白了还是钱的问题”

随着这些年国内互联网的发展，网民对线上娱乐需求的不断增加，这些需求的增长也对各大服务提供商（比如bilibili/爱奇艺/腾讯视频/淘宝）等站点的流量提出了不小挑战。为了提供尽可能好的网络体验，服务厂商需要购买网络带宽分发他们的资源，让用户能够就近高速访问，因此CDN网络成本成为了一块重点支出费用。与海外的运营商建设和运营模式不同，中国大陆的网络基础设施只能由持牌的三家基础运营商（电信联通移动）进行建设，因此国内服务商也只能从运营商购买合规的网络资源。众所周知这几年尤其是疫情之后，降本增效变得尤为重要，在厂商和运营商之间来回拉扯之下，某些省份分公司出于营收和业绩要求，以低价吸引大客户的方式对外出售带宽资源（比如2k/gbps/月的单线cdn带宽）。所以局面和趋势不难理解，大厂为了成本选择低价省份带宽，用来服务其他省份的同网用户，而其他价格比较高不划算的省份，建设了网络却不好卖，有的省份营收投入不匹配赚不到钱，而更进一步，有些省份间出于一些原因（比价、压价、抢客户）带宽价格又出现恶性竞争，卖的多了却赚不到钱。

为了缓解这个问题，2024年初，国内运营商发布内部文件，开始实行网内省间流量结算政策。这个政策主要是为了避免省份间CDN业务的恶性竞争，导致业务集中于某些低价省份的同时，其他省份光有投入，却没有营收收入的问题。结算方式是，流出的省份向流入省份按照一个单价支付结算费用，比如如果一个服务器在广东，而用户从湖南访问，那么流出方向就是广东到湖南，广东省需要按照流出流量，给湖南的运营商支付费用。

从政策出台以后，为了避免省间流量结算导致本地公司的收益问题，各地市运营商开始对跨省流量进行控制，首当其冲的就是PCDN。

PCDN （P2P CDN，与迅雷等点对点协议比较类似，但用于内容分发），常见的包括京东云、网心云等产品，这类产品以用户宽带“闲置”上传带宽为其他用户提供服务，并给与参与的用户一定利益（包括积分兑换礼品甚至现金奖励等）。众所周知，国内家庭宽带其实某种意义上是带了补贴性质的，主要以非商用目的，网络基建化，全民用得起，所以价格对比其他国家并不高，而PCDN这种利用低成本家宽实行商业内容分发的，对运营商来说，本质是在薅运营商羊毛，但是对于服务商来说，这也是没办法的事情 – 服务商找电信运营商购买带宽用于内容分发的价格远高于PCDN这种“野路子带宽”，从成本和效果上，PCDN都是降本增效的利器，所以头部服务商，包括bilibili、抖音、爱奇艺等其实都有一定程度上使用PCDN来作为他们视频资源分发的渠道之一。甚至于，PCDN曾是阿里云的一项公开服务。

现在省间结算要求运营商保护自己的营收以后，这种PCDN高上传带宽利用的自然就成了运营商的眼中钉，限速的限速，拉闸的拉闸。这也就导致了过去一年多时间相当多正常上传的用户，因为高上传被打上了限速，投诉无门，哪怕是正常的传文件到网盘，流量大了也会被限速，因为省间流量结算之后，高上传尤其是跨省上传对于运营商来说就是纯负收益，再加上有些运营商不愿意做细化分析针对打击，干脆一刀切，也因此对正常用户造成了影响。

可是这些问题又怎么难得倒PCDN的服务商呢，既然运营商的结算目标是本网跨省，那么格局打开，这些人瞄准了“不结算“的跨网互联。

办法总比困难多

2020年，工信部发布《关于调整互联网骨干网网间结算政策的通知》，通知中明确

“自2020年7月1日起，取消中国移动通信集团有限公司（以下简称“中国移动”）与中国电信集团有限公司（以下简称“中国电信”）、中国联合网络通信集团有限公司（以下简称“中国联通”）间的单向结算政策，实行对等互联，互不结算。”

以及随后的几年间，三家运营商在各个省份建立起了各自的互联节点以后，跨网流量主要就以省份（或者就近省份）互联传输为主了。

恭喜你发现了华点，既然现在本网内跨省有限制，跨网没有，那转而选择用不需要结算的跨网互联服务异网用户，那不就行了嘛（滑稽）。所以PCDN的应对措施就是，给电信用户分配联通移动的PCDN边缘，联通移动则给电信的节点。这样你省间结算总管不到我了吧。所以明面上来说，因为跨网流量的增长，24年6月份开始有些省份的跨网互联就陆续出了问题，表现明显的就是广东和江苏，电信访问移动的网络会在高峰期出现丢包的情况，显然是互联塞了。

爆炸还得加点火（药）

光PCDN能造成这个局面吗，显然是不够的。PCDN能提供一定的流量分发，但是总归会有一些技术层面的问题（包括稳定性、调度等）。尽管PCDN可以一定程度上降低分发成本，但是明显不可能全靠这玩意儿，所以正规的CDN该买还是得买。

但是问题来了，运营商的报价也是有一定差异的。电信作为国内运营商的“老辈”，专业度和网络建设比起另外两家都“好一些”，所以价格也明显的，贵一些（这一点不管国内国外价格都差不多，国际互连价格可以参考我之前的文章：三大电信运营商国际互连相关资料）；而移动作为后起之秀，为了抢占市场，低价竞争拉客户也是移动的惯用手段之一（可惜运维和技术确实差了电信一截）。总的来说，国内IDC/CDN带宽费用上，大概是电信>联通>移动的一个情况。

现在我们假设一个情况：你需要去服务电信用户，电信给你报价15块/Mbps，本网质量能保证100%的需求；联通给你报价10块，但是跨网有些许丢包，能满足你60%的需求；移动给你报价5块，丢得有点多，但是能满足30%业务需求，现在你是业务负责人，从成本和业务需求的角度考虑，你会怎么选择？

对于一些头部大厂来说，他们的选择是：用便宜的异网，去覆盖本网用户，满足一些低价值，或者说用户感知不强烈的场景的内容分发。（具体就不多说是哪些厂了）。这些头部厂商用户基数大、流量需求高，再加上跨网这么一折腾，跨网流量也是越发爆炸。

那就有人会问了：”跨网塞了，工信部又发文说不用互联费用结算，运营商干嘛不扩容啊？“

嘿嘿，虽然明面上说是没有互联结算费用，但是在某些省份（比如广东），电联移动实际上还是有私下的结算的。

没想到吧.webp

电信：你现在塞了，要么加钱，要么炸

移动：炸就炸吧，反正我不出钱

那你可能又会问了：“你电信贵的人家宁可异网覆盖都不买你带宽，你TM不能降个价吗”

电信：你猜猜我是为了什么才搞这么些操作的？

看看本文开头，也许大家心里也会有一定理解了。

所以。。。影响了些什么？

主要影响了移动和联通传送至电信方向的流量质量，例如：

• 广东电信访问广东移动的资源，速度仅有1Mbps
• 联通到电信上传只有几十几百KB/s
• 联通移动到电信方向高强度丢包和延迟爆炸（例如广东联通到广东电信30ms+的延迟）

并且由于是跨网拥塞，对于移动到电信的另一个坏消息是，就算是移动对标电信的CMIN2精品网，因为只有跨境段独立容量，而国内互联到电信还是9808和4134的互联，因此不管你是CMI还是CMIN2，回程到电信的速度都非常稀碎。其实这一点对10099-4837回电信也是同样的影响，只是炸的没移动那么厉害。至于9929回电信，或者CN2回联通，因为4134-9929 和 4837-4809有单独的互联，所以跨网互联拥塞受影响有限。

至于电信回另外两网的方向，因为相对而言需求不是那么高，所以质量没有联通移动回电信炸的这么离谱罢了。

船新的折（bai）腾（piao）系列，果然免费的最贵，费时间调试麻烦死了。

众所周知，Azure的国际版对每个订阅有白给的10个App Service F1应用计划的额度，这个订阅不管是Azure for Student (也就是学生100刀）、Pay as you go (即用即付），或者VSE订阅都是有效的，更有甚者，如果你有远古时期的Microsoft Imagine 订阅（现在的Azure for Student Starter，订阅OFFER ID ms-azr-0144p），这些东西也是可以直接用的。

既然MS在Azure给了为数不多的所谓免费资源，能物尽其用那当然是最吼的。这段时间发现App Service支持Docker Compose部署资源了，索性折腾了一下尝试在这上面部署了一个next-terminal。

虽然F1实例的资源限制比较感人（每个F1应用计划1G存储，1G内存，每月5G流量按每天165MB累加计算，每天60分钟CPU，折合下来就是全天均值CPU利用率不超过5%左右），对于不需要通过堡垒机/跳板机传输大数据、文件的一般console运维场景，这个资源完全够用了。

废话不多说，开始操作。

部署

首先访问这里（https://portal.azure.com/#create/Microsoft.WebSite），选择你的订阅和资源组，然后输入应用名称（这个名称也是你后面访问next-terminal的域名，格式是 <appname>.azurewebsites.net ）

区域的话根据需要选择，下面是一张快速检索表，如果是需要从国内访问，建议选择新加坡或者日本以获得最佳体验，次选香港，因为Azure到国内三大运营商目前只有东京和新加坡的互联，香港和其他地区都得绕这两个地方。

然后点击下一步，这里按照下图所示，会需要上传一个docker-compose.yml文件

这个文件的内容如下：

version: '3'
services:
  guacd:
    image: dushixiang/guacd:latest
    environment:
      WEBSITES_ENABLE_APP_SERVICE_STORAGE: TRUE
    volumes:
      - ${WEBAPP_STORAGE_HOME}/ntdata:/usr/local/next-terminal/data
    restart:
          always
  next-terminal:
    image: dushixiang/next-terminal:latest
    environment:
      DB: sqlite
      GUACD_HOSTNAME: guacd
      GUACD_PORT: 4822
      SERVER_ADDR: 0.0.0.0:80
      WEBSITES_ENABLE_APP_SERVICE_STORAGE: TRUE
    ports:
      - "80:80"
    volumes:
      - ${WEBAPP_STORAGE_HOME}/ntdata:/usr/local/next-terminal/data
    restart:
      always

这里做的事情：

• 将Next-Terminal在docker内部暴露在80端口
• 将 /home/ntdata 挂载到容器内部（以便于你持久化数据），写成 ${WEBAPP_STORAGE_HOME}/ntdata 是因为Azure的要求必须这样的格式，否则会无法启动。你可以自行修改挂载的目录

然后直接快进到“审阅+创建”就好，毕竟免费的App Service很多事情都没什么可以配置的。

在创建完毕以后，我们需要

• 修改配置，允许挂载磁盘空间
• 修改next-terminal所使用的sqlite文件对应的journal mode为wal，否则next terminal会因为数据库被锁导致初始化失败，进而服务不可用。（这个问题是因为App Service内挂载的这1G的文件空间是通过CIFS挂载的）

首先点击实例详情页左侧的”配置“，在”Application Setting”下看是否存在”WEBSITES_ENABLE_APP_SERVICE_STORAGE“这个选项，如果有的话，点击，然后修改Value为 TRUE，完了直接点击OK。如果没有的话，点击“New Application Setting”，然后Name输入 WEBSITES_ENABLE_APP_SERVICE_STORAGE ，Value输入 TRUE （注意都不要有空格)。修改/新增完毕以后，点击上方的”Save“保存。

然后转到这个新建的App Service实例详情页，点击左侧的 “开发工具”下的“SSH”，然后转到SSH。如果一直卡在红色的SSH CONN的话，也可以选择点击下面的“高级工具”进入以后点击新页面上方的Bash选项进行操作。

切换到 /home/ntdata/ 目录（请注意这个目录是前面Docker-compose.yml里面定义的挂载的文件夹，如果你有修改的话，需要进到对应的目录），然后运行下面的命令

rm /home/ntdata/sqlite/next-terminal.db
[ ! -d /home/ntdata/sqlite ] && mkdir /home/ntdata/sqlite -p
sqlite3 /home/ntdata/sqlite/next-terminal.db 'PRAGMA journal_mode=wal;'

在回显 ‘wal’ 之后，返回App Service详情页面，点击左侧“概述”，然后点击“重启”，等待一段时间（大概5-6分钟）之后，next-terminal应该就启动了。

这时候你就可以通过下面显示的地址访问到next-terminal了，默认的管理员账号密码都是 admin

其他注意事项

• 如果需要数据备份的话，直接将 /home/ntdata 下的内容打包备份即可。
• 正如前文所述，F1实例是有资源限制的，你可以在左侧的“配额”一栏看到使用情况。这个东西本身比较轻量所以一般情况下个人日常使用应该问题不大。
• 免费的App Service在一段时间不活动以后就会进入休眠状态，下一次打开的时候可能会花上数分钟才能启动，一种方法是使用CF或者AWS的Serverless function，每10分钟curl一次你的访问地址，只要间歇性有访问流量，就可以大概率维持app的存活状态
• 这个东西只限于图个乐，不建议用于生产环境，个人折腾折腾学习还是可以的。
• 如果部署存在问题，你可以点击左侧“部署”选项下的“部署中心”，点击“Log”查看错误日志。
• 使用这个方法你也可以类似的部署其他可以使用Docker-compose部署的容器服务，如果是Web服务，你需要确认docker-compose.yml内至少有一个expose 80或者8080端口的容器接收明文HTTP请求。

参考资料

• Multi-container Linux Web App (链接)
• Create a multi-container (preview) app using a Docker Compose configuration（链接）

最简单的办法那当然是nginx去follow 302请求，比如

server {
    ...

    location / {
        proxy_pass http://backend;
        # You may need to uncomment the following line if your redirects are relative, e.g. /foo/bar
        #proxy_redirect / /;
        proxy_intercept_errors on;
        error_page 301 302 307 = @handle_redirect;
    }

    location @handle_redirect {
        set $saved_redirect_location '$upstream_http_location';
        proxy_pass $saved_redirect_location;
    }
}

当然，我这人属于闲的蛋疼的那种，本着不折腾白不折腾的原则，研究了一下blob服务器的规律。实际上，msdl最后302的域名格式最终都形如“vsblobprodscussu5shard29.blob.core.windows.net”，其中加粗部分就是存储账号的名字，最后的‘29’是分区的编号，范围1-99。

返回回来的下载链接类似于：

https://vsblobprodscussu5shard29.blob.core.windows.net/b-4712e0edc5a240eabf23330d7df68e77/0F751EB0FD2CCF2FA0E24E4FD662F0D2BF37968BC915CB4E2B2ABD508E226A5600.blob?sv=2019-07-07&sr=b&si=1&sig=BxJ9VQUw8xEBO8iMOW6ktDtXNbXsEmZIiApS2B.......

所以只要想办法把这条302请求rewrite到自己定义的一个目录下，配合正则表达式抓取其中的存储账号名称就可以了，然后在反代的时候带上签名query string请求blob文件。

最终实现的效果

curl 'https://msdl.sunflyer.cn/download/symbols/imm32.pdb/265BCB59F6886A8F9F482A4A4903527B1/imm32.pdb' -vL
*   Trying x.x.x.x:443...
* TCP_NODELAY set
* Connected to msdl.sunflyer.cn (x.x.x.x) port 443 (#0)
> GET /download/symbols/imm32.pdb/265BCB59F6886A8F9F482A4A4903527B1/imm32.pdb HTTP/2
> Host: msdl.sunflyer.cn
> user-agent: curl/7.68.0
> accept: */*
> 

< HTTP/2 302 
< server: nginx
< date: Wed, 01 Jun 2022 13:01:12 GMT
< content-length: 0
< location: https://msdl.sunflyer.cn/msdl/blob/vsblobprodscussu5shard29/b-4712e0edc5a240eabf23330d7df68e77/0F751EB0FD2CCF2FA0E24E4FD662F0D2BF37968BC915CB4E2B2ABD508E226A5600.blob?sv=2019-07-07&sr=b&si=1&sig=vm5C........
< x-cache: TCP_MISS
< x-msedge-ref: Ref A: AB9FDF8E2EC24843B2FC5106804646E2 Ref B: LAXEDGE1612 Ref C: 2022-06-01T13:01:12Z
< 
* Connection #0 to host msdl.sunflyer.cn left intact

* Found bundle for host msdl.sunflyer.cn: 0x562d2e23a030 [can multiplex]
* Using Stream ID: 3 (easy handle 0x562d2e2422f0)
> GET /msdl/blob/vsblobprodscussu5shard29/b-4712e0edc5a240eabf23330d7df68e77/0F751EB0FD2CCF2FA0E24E4FD662F0D2BF37968BC915CB4E2B2ABD508E226A5600.blob?sv=2019-07-07&sr=b&si=1&sig=vm5........ HTTP/2
> Host: msdl.sunflyer.cn
> user-agent: curl/7.68.0
> accept: */*
> 
< HTTP/2 200 
< server: nginx
< date: Wed, 01 Jun 2022 13:01:13 GMT
< content-type: application/octet-stream
< content-length: 241664
< content-language: x-e2eid-8a548e8f-775640f8-92f75c6a-39acad2f-session-0f6f7bb5-6af84688-81185f71-f1a680c2
< last-modified: Thu, 19 Nov 2020 21:38:25 GMT
< accept-ranges: bytes
< etag: "0x8D88CD371ED33BF"
< x-ms-request-id: 33f4d3e6-501e-00e0-1fb7-7570d0000000
< x-ms-version: 2019-07-07
< x-ms-creation-time: Thu, 19 Nov 2020 21:38:25 GMT
< x-ms-lease-status: unlocked
< x-ms-lease-state: available
< x-ms-blob-type: BlockBlob
< x-ms-server-encrypted: true
< access-control-expose-headers: Content-Length
< access-control-allow-origin: *
< x-upstream-server: vsblobprodscussu5shard29.blob.core.windows.net
< x-upstream-path: b-4712e0edc5a240eabf23330d7df68e77/0F751EB0FD2CCF2FA0E24E4FD662F0D2BF37968BC915CB4E2B2ABD508E226A5600.blob
< 

* Connection #0 to host msdl.sunflyer.cn left intact

Nginx配置文件如下

location / {
		proxy_pass https://msdl.microsoft.com;
		proxy_http_version 1.1;
		set $addr $remote_addr;

		proxy_set_header X-Forwarded-For $addr;
		proxy_set_header Connection '';


# 这一行将msdl服务器返回的302重定向到我自己的/msdl/blob/<存储账户名>/<文件路径> ，然后再实际请求对应的文件
		proxy_redirect ~https://(vsblobprodscussu5shard([0-9]+)).blob.core.windows.net/(?<filepath>.*) /msdl/blob/$1/$filepath;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header Host msdl.microsoft.com;

		proxy_ssl_name msdl.microsoft.com;
		proxy_ssl_server_name on;
	}

# 实际的反代请求到对应的blob目录
	location ~ /msdl/blob/(vsblobprodscussu5shard([0-9]+))/(?<filepath>.*) {
		set $blobhost $1.blob.core.windows.net;

		add_header X-Upstream-Server $blobhost 'always';
		add_header X-Upstream-Path $filepath 'always';

# 需要带上 $args （query string包含blob签名，否则请求会404）
		proxy_pass https://$blobhost:443/$filepath$is_args$args;
		proxy_set_header X-Forwarded-For $addr;
                proxy_set_header Connection '';
 		proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $blobhost;
		proxy_ssl_name $blobhost;
		proxy_ssl_server_name on;
	}

你问我这么做的好处都有啥？没有，其实就是闲的蛋疼折腾一下（草），这个方案比较浪费性能（因为正则表达式解析的问题），所以如果不是跟我一样闲的蛋疼的话建议直接nginx里面follow 302就好了。（大草）

哦当然，如果你有需要的话可以拿这个镜像去用，地址是 https://msdl.sunflyer.cn，替换 https://msdl.microsoft.com 就好了。比如常见的地址应该是 https://msdl.microsoft.com/download/symbols，那就改成 https://msdl.sunflyer.cn/download/symbols

0. 太长不看

腾讯云的虚拟网络VPC对TCP MSS的clamp机制不当，导致当对端用户发送超过1500的TCP MSS的数据包给腾讯云端的服务器时，两端协商出的MSS会导致TCP传输过程中数据包过大（大于中间链路的MTU），被中间路由器丢弃，影响HTTPS连接等业务场景。

1. 问题分析

我在今天检查甲骨文云（Oracle Cloud）服务器上脚本运行情况的时候发现某个定时从腾讯云服务器上拉取数据的脚本全部超时，经过手动curl测试，发现HTTPS请求会卡在TLS握手阶段，无法接收到从腾讯云发回的Server Hello数据包。

根据以往经验，多数情况下该问题由本地或者中间路由的MTU配置不当导致数据包过大，加上TLS握手包一般会被标记为不允许分片，从而中间路由器无法处理大包时会将其丢弃。经过检查，腾讯云的MTU为1500，而甲骨文云的MTU为9000（因为甲骨文的虚拟网络内部开启了Jumbo Frame）。

开始排查问题，使用tcpdump在两侧服务器抓包发起请求，甲骨文云侧的数据显示MSS为8960。

腾讯云侧收到的数据包MSS为8924，少36字节

而腾讯云回复出去的MSS为1460（网卡MTU 1500 – TCPIP头 40 = 1460）

而甲骨文一侧实际收到的MSS是1424，也少了36字节。

注意，此时握手已经成功，腾讯云侧的服务器在发送数据时按照MSS 1460发送（因为甲骨文收到的MSS是中间路由给clamp过后的mss，而非腾讯云服务器本身发出去的MSS），因此这个时候一个TLS握手发出去的TCP包就有可能实际长度为 1460 字节，大于中间链路所允许的MTU，因此数据包被丢弃，表现为你可以看到后续由443端口发出的Server Hello数据包重传。

经过多番测试，对于入向的TCP数据包，腾讯云对其进行clamp的方式是如果MSS大于某个数值，直接减少36字节，而不是将其设置为大于某个阈值之后clamp到链路MTU。如果对端服务器类似于甲骨文云开启Jumbo frame，且不对出向流量做clamp的话，就会因为clamp过后的实际MSS过大，而两边在约定发送的段长度时会以小的一方为主，但是在这种情况下显然 8000+>1460，因此腾讯云的服务器会误以为使用1460作为MSS即可正常发送TCP数据包，从而导致最终业务数据包长度超过中间路由器的限制，TLS握手这类不允许分片的数据出现丢包。

2. 额外发现

在工单里来回帮忙测试的时候，腾讯云的客服最开始使用ping大包的方式来测试网络是否正常。然而根据后续测试，我发现腾讯云虚拟网络对于ICMP数据包也有额外处理。

经过测试，即使对icmp设置了不允许分片，腾讯云的虚拟网络在传输的时候还是会将大包进行分片处理，所以是能通的，而对于TCP包设置了不允许分片的则会被丢弃，两种协议的行为不一致。

使用以下命令来设置DF（Don’t Fragment）：

ping <ip> -M do -s 1472

可以看到腾讯云的回复数据包是存在分片的，而另一方面，腾讯云收到这个数据包的时候，DF标记却没了

为了避免是我理解问题，我特地用这台测试机器ping了另一台日本的机器，结果是正常的，DF标记未被修改。说明腾讯云对ICMP的大包传输实际上是无视了DF标记位强行分片。

3. 结论

这个问题是腾讯云虚拟网络对MSS的不当处理导致的，按照正常机制来说TCP MSS Clamp应该将其限制在链路能承载的范围之内，而不是盲减36这种奇葩做法。

此外，由于对ICMP的特别处理（无视分片标记位强制分片大包），这有可能会影响部分依赖于PMTUD的应用程序。

对于影响TCP业务的临时解决方案为，自行在mangle表内对MSS进行clamp，使其小于或等于1424。

iptables -t mangle -A INPUT -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1461:65535 -j TCPMSS --set-mss 1424

重要的事情说三遍。

去年趁着公司发的购物卡额外自己花了两千多块钱买了OPPO Reno 4，5G刚出来那会儿想尝个鲜，在此之前受够了MIUI的一堆广告弹窗（ADUI名不虚传），但是又不想换苹果，因此换一个另一个国产，也就买了这玩意儿。

然后买回来没多久发现这玩意儿更坑爹，首先，OPPO钱包里面一堆“服务”，关闭只能一个一个手动关闭，但是如果你一不小心点了“一键开启所有服务”，那就“诶嘿~老子全回来了”让你有一种急的想骂娘的感觉。其次，系统内置应用推送一个接一个，前有应用商店开屏广告一不小心就会点到全部安装，后有各种迷惑推送无法解决，百般无奈之下这手机用了不到半年就送去吃了灰转回了苹果大法。

然而最近LOL手游公测，只有安卓版本，所以又不得不掏了回来，这一掏妈的心脏病都要犯了，玩游戏卡的跟PPT一样，而且系统的视频应用会一天给你推两条消息，对我这种有强迫症的人来说十分不爽，于是在任务栏里面按了“关闭通知”。然而即使如此这个该死的傻逼推送依然还是会每天定时到达—只要你连了网。然后当你十分心烦想要在系统设置里面删除它的时候你却发现他只能被“卸载更新”，甚至连停用也没有。

然而根据官网说明，这个视频应用是可以卸载的。

真的可以卸载？当然可以，只是你不能在手机里面卸载。我现在严重怀疑coloros这帮司马开发和产品经理是不是户口本只有一页了才想出来的这么些恶心人的东西。

然后到了C版本的时候，这个东西就变成不可卸载了。我不知道这个所谓遵守暂行管理规定你们是遵守到哪个屁眼里面去了。

为了解决这个SB视频应用，我先尝试adb shell列举了应用包然后删掉了唯一一个包名里面带有video的应用，然而这个死马玩意儿还是存在，万般无奈之下搜寻了一阵找到如何定位当前前台应用的包名。然后删掉了这个死马东西。

具体怎么做：

1. 首先你需要启用开发者模式，（系统版本号连点五次就会出来选项），然后进入开发者模式允许USB调试
2. 手机使用USB连接电脑，然后使用adb shell连接到你的机器，注意在手机屏幕点击允许调试
3. 运行 pm uninstall -k –user 0 com.heytap.yoli，如下图所示（没想到吧，这个package名叫 yoli，谁他妈知道一个视频应用名字里面一个video都没有，充分凸显了OPPO是有多么的死马）

然后等提示Success，这个死马玩意儿就从你的手机里面虚无了。同理你也可以使用这个命令卸载其他的自带应用，典型的死妈应用列表如下：

如何定位某个应用对应的包名称？adb shell之后，手机打开你想要找的那个应用，保证他在前台屏幕显示，然后在shell窗口内输入 dumpsys window | grep mCurrentFocus，你就会看到上述图里面所显示的 mCurrentFocus = Window{xxxxxx u0 com.heytap.yoli/xxxxxActivity} 一类的东西，其中斜杠前面那个 com.heytap.yoli 就是对应的包名，然后使用 pm uninstall 去卸载它就好了。

最后再说一句：OPPO NM$L。

上周给同事做网络相关的内容分享的时候，有同事问有没有一个稳定的镜像服务来代理/加速Github代码操作的，考虑到国内比如gitee之类的可能比较麻烦还要注册账号clone之类的，因此自己找了一台相对比较空闲的服务器，自己弄了个github的镜像。

这个镜像服务的地址可以在这里找到.

有何差别？这个镜像只加速通过git命令行产生的操作，比如git clone/fetch/pull，而且使用非常简单，只需要将你原来命令里面的源地址由github.com替换为镜像站域名就好了

比如git clone dotnetcore:

git clone https://github.com/dotnet/core.git

你只需要将其中的 github.com 替换为 github.sunflyer.cn 就好了

git clone https://github.sunflyer.cn/dotnet/core.git

其他的比如git fetch/pull一类的，如果你之前的origin已经设置为github, 只需要自己讲origin的域名修改为镜像站的域名。

速度差异有多少？下面是一个对比。

使用github.com直连：（中国联通网络环境下）

使用镜像站：

反正就是保持在一个更快的速度，就完事儿了；）

Note:

• 现已支持git clone 的 recursive clone了，正常用法即可
• 镜像站只支持从中国大陆地区访问，毕竟网速问题是国内特有现象，而且海外访问github并没有过多的连通性问题，为了节省服务器流量因此简单屏蔽了境外的请求。如果访问镜像站提示错误，请确保你处于正常的国内网络环境下，并且没有使用类似于Google(8.8.8.8)或者Cloudflare（1.1.1.1）等境外的公共DNS服务，以免分区域解析至境外地区导致无法正常使用。
• 此镜像站偶尔速度可能比较缓慢，取决于联通上海出口的拥塞情况。一般期望的速度应该在2MB/s或以上。

此外，

* 镜像站不缓存，也不留存任何关于镜像产生的行为的数据，因此不涉及隐私问题。

** 由于此镜像构建在本人空闲的服务器上，服务器存在每月流量限制（2TB），因此当流量用尽时需要等待次月恢复。

*** 请在符合当地法律法规的前提下使用此镜像服务，本人不承担任何因使用此镜像产生的连带责任。

**** 出于防止某些滥用的考虑，镜像仅支持通过本地使用 git 命令（例如git clone/git pull）加速，不支持直接在浏览器内替换为镜像地址以后访问对应repo！

如果有任何问题，欢迎在评论区留言。

最后更新于 2025年2月20日

本文内所有内容均来自于自身工作了解、IDC圈的从业人员以及运营商内部工作人员，与其他任何博主的文章无关，转载请保留出处（https://blog.sunflyer.cn/archives/594）

前置知识

由于国内政策和网络安全要求，中国国内运营商在处理公网跨境流量时对骨干设备进行了分类，一般包括C-I-X-F四段。其中C段表示中国大陆国内段（核心路由器），I段表示跨境段（国际出口路由器），X表示运营商海外互联中继（国际网间互联路由），以及F段表示与海外其他运营商的互联路由（海外POP点）。

一般而言，C-I段部署在国内，I-X-F段则依据对端互联运营商所在地有所差异。国家跨境数据安全网关部署在C-I段中间，三大运营商此段容量也因为安全设备容量原因而有所限制。

由于国内目前的销售策略（商宽补贴家宽等情况），商业用途的带宽比起家庭用户要昂贵许多，大家可能习惯了99元月付的千兆家宽，然而国内动态BGP带宽（仅国内穿透，不包括国际穿透）的价格就能达到至少 100CNY/Mbps/月，这点在国际互联的带宽费用上也有所体现–中国主流的三大运营商拥有超过数亿的用户群体，对于这样庞大的Eyeball网络尤其是中国大陆这样的封闭市场，用户群即是他们的核心竞争力和要价资本（这一点可以参考中国移动近几年的宽带白送抢占客户群的操作），因此对于服务商而言，越是想低延迟、高质量服务这类网络下的用户，所需要付出的成本越高。

所以与许多人的直觉相反，在实际的报价和互联处理上，离中国大陆越近，延迟越低，带宽互联越昂贵。香港地区是三家运营商所需要的互联费用最高的地区，其次是日本、新加坡、韩国，然后是俄罗斯，最后是欧美地区。至于原因，在中国大陆提供公开的互联网信息服务（例如传统网站服务）存在多样的问题，除了政策层面的需要提供ICP备案接入以外，对于非BGP接入的机房，2024年7月开始的网内跨省流量结算以及PCDN的打击和跨网调度应对，导致的一系列跨网拥塞问题，因此尽管单线静态接入的带宽费用相对而言比较便宜（例如广东移动单线可以做到6000/gbps的价格），但是现在的跨网爆炸很难通过单线服务国内三网的所有用户，所以如果海外地域以“离国内越近越便宜”的价格来销售，那么可以看到的是长途线路几乎会很难卖的出去，影响运营商的利润和投入回报。

在这样的策略影响下，因为成本等方面的原因没有在亚太地区购买三家运营商直连线路的服务提供商，将不得不通过Tier 1 Transit来将他们的流量传输至国内，而Tier 1 Transit的带宽也是有限的，例如，NTT在亚太地区和中国电信163的互联仅有60G（NTT曾试图联系电信扩容但价格过于昂贵），而多数亚太的服务商（例如Vultr/Linode/DO)由于BGP路径选择，默认情况下会优先这类网络，因此原本狭小的互联只会更加拥塞。而电信是没有意愿主动扩容的：如果流量都走Tier 1，那么作为他们营收的主要部分，paid peer就没法达到预定收益。

基于这个原因，从逻辑互联来说，对于大多数服务提供商，香港虽然是离大陆最近的地区，但却不一定是国内访问最快的地区。而总结起来，从网络拓扑来说，在中国大陆常见的遇到的海外访问问题包括：

1. 非三大运营商直连客户：
   • 经过Tier 1 Transit (比如NTT, GTT, Level 3)由于运营商-Transit Provider之间的容量原因以及普通网络跨境段（C-I）容量限制出现的高延迟、丢包和低速率。典型场景：电信-日本NTT长期高度拥塞导致的丢包和延迟上升，众多开源软件的源服务器（Ubuntu PPA/Debian Mirror等）至国内低速率下载
   • 非优化流量绕路，例如新加坡Singtel至中国电信对非优化流量通过其他Tier 1 （i.e. AS6453 TATA)绕路美国导致高延迟
2. 三大运营商直连客户：
   • 普通网络跨境段（C-I）容量限制出现的丢包问题，典型场景：国内电信访问微软国际版服务（比如Office 365, OneDrive）； Cloudflare至中国电信用户的速率问题
   • 商家或者提供商由于带宽没买够跑爆了或者有QoS问题导致的速度问题，典型场景：腾讯云香港普通网络

中国电信

中国电信目前维护三张网络：AS4134 ChinaNet (163), AS4809 ChinaNet Next Generation Carrier Network (CN2) 以及 AS23764 CTGNet

# ChinaNet

ChinaNet(a.k.a. 163)，主要城市如LAX、SJC、FRA、LON，回国带宽大，但因电信超卖严重，因此尖峰时段较容易阻塞，同时也常有来自中国境内的流量攻击将出口塞满。价格较低。

于目前（2020年8月）163网国内至国际互联段（C-I段）容量拥塞，因此访问国外一些服务商会出现严重的慢速、丢包、高延迟等现象。

2022年9月：163国际出口扩容大约1T左右，推测为早前的扩容计划推迟至最近才完成。

2021年：按照集团规划，163国际出口国内段扩容预计在2021年2月底之前完成。 中国电信和中国移动在2021年3月底4月初左右对163和CMNet的国际出口进行了扩容，据信总带宽约1.2Tbps左右，国际段拥塞情况相对之前已缓解不少，但广州和上海出口的部分路由仍然存在丢包情况。电信目前在对163进行国际互联国内段流量管理设备招标，据招标内容显示本次采购的设备用于 58 x 100Gbps 的国内段链路的流量管理，因此推测今年暑期或者下半年应该还有一次国际出口段的扩容操作。

2023年11月：电信阳光采购网于8月15日发布《中国电信2022年ChinaNet国际网络(国内段)流量综合管理系统扩容工程集成服务询价结果公示》，此次扩容是电信于2022年规划但是直到今年才获得工信部批准，根据观察近期（12月初）国际出口已有比较明显的好转。原文链接, 根据Cera Network大佬的消息，中国电信本次广州出口扩容1.8Tbps.

2025.02 中国电信于2月18日发布了2024年规划的国际网络（国内段）流量管理系统招标公示，预计电信会在接下来数月内完成跨境段扩容，本次招标还提及了设备交货位置，除以往的北上广以外，本次还新增了海口和昆明，据信是部署在新增的国际出入口局。此外还与以往相同提到了相关设备的要求，包括DPI、访问控制、日志、流量归类等方面。（原文链接）

对于IPT的价格：北美163单价（指每Mbps的价格）大约为 $0.6 ，而在日本/新加坡则为<=$20，香港则是丧心病狂的 $50+ (香港这个价格为2020年左右的IPT合约价格）。然而即便价格昂贵至此，电信的标准付费互联并不带任何质量保证，全是Best Effort，还是你电信会赚钱。

如果是跨境段（C-I）高保障QoS的163（质量参照上海电信家宽国际精品网，或者世纪互联版Azure），香港地区的IPT单价则超过 $75，几乎快接近CN2 GIA的底线价格。

（上述价格，包括下面提到的联通和移动的IPT价格，都是commit量比较大的情况的折扣价格，一般在8折左右（甚至可以更低），因此实际在commit量少的情况下价格会更高。另外，单位并没有弄混，就是美元，你没有看错）

# CN2 GT (Global Transit)

CN2 GT，163与CN2 POP之间统一在上海、广州、北京三个互连点，北京互连点应为一年内所新增。同上一点所属，由于两张网流量交换前也会经过163的汇聚点，因此也较容易因163汇聚点有大量攻击流量导致阻塞，同时因攻击塞满两张网之间的互连也时常发生。

对于跨境互联质量，电信官网承认CN2 GT与ChinaNet质量无异。换句话说就是，CN2 GT集成了电信两张网各自最烂的部分：CN2海外的憨批骨干质量和163出口的傻逼跨境段质量。

欧美地区的CN2 GT或将在接下来规划下线，现有CN2 GT的客户（已知的包括QuadraNet AS8100, 俄罗斯DataLine等）将被切换至163。但正如前文所述，在跨境质量上CN2 GT和163因为是共享C-I段，因此在质量上并不会有差别或者变化。

# CN2 GIA (Global Internet Access)

GIA与GT之间所经过的跨境互联段不同（即C-I段），其中GIA有单独的C-I段容量，而GT则与163共享C-I段，因此基于目前的跨境互联质量而言，CN2 GT与163几乎没有差异，但GIA与GT/163则会有明显体验上的差异。该产品在163与CN2两张网之间互连有独立的端口进行互连，互连点也较多，采就近接入原则，但实际上延迟不一定比较好。且因互连点不同关系，实际上有可能会出现某地至北美GT走上海出口，但GIA却走广东出口等等差异。另互连端口在有大量攻击时容易阻塞。特别是南京、北京互连点。

电信报价依据所在地与中国大陆之间的延迟决定，延迟越高价格越低，如北美大约6 USD/Mbps (目前可能已涨价），而香港地区的CN2 GIA单价最高则达到了100 USD/Mbps，底线价格也有接近$80（但应该很少能有以这个价格拉到的）。2022年3月份左右CN2的跨境段容量峰值使用率已超过90%+，电信集团目前已经暂停了部分方向新接的CN2 GIA的订单（除非有释放的带宽资源，释放多少批多少）。

与AS4809直接互联的CN2 GIA产品在亚太和欧洲地区已经下线，目前新接客户需要通过CTGNet。

CN2于2021年4月发布了设备扩容采购招标公告（见 这里），推测今年年内完成扩容。（看来是咕咕咕了的样子

# CTGNet (AS23764)

由于通过CTG/CTA/CTE购买GIA带宽需要中国电信集团级别审批合约，因此CTG自己搞了个CTGNet（自卖自销系列），据大佬介绍CTGNet订购的带宽合约目前暂不需要集团审批。在今年年底某个时间点以后新开的合约都需要走CTGNet签订。目前电信正在将已有的AS4809客户迁移到CTGNet，亚太地区比如香港和新加坡已经迁移不少客户，包括阿里云香港、腾讯等，今后新开的大部分CN2合同都会变成CTGNet的合同。

CTGNet包含了之前的163/CN2 GT和CN2 GIA的接入，区别是根据合约报价来决定最终互联的质量，钱给的多就给你GIA，钱给的少那就是GT甚至163。

目前亚太和欧洲（除俄罗斯以外），原有的CN2 AS4809的客户大部分已经迁移至CTGNet下。

CTGNet常见的骨干网IP开头为 69.194 和 203.22，均在AS23764下。

与过去直接和AS4809接入的CN2 GIA对比，从腾讯云新加坡订购的CTGNet的路由来看，除了中间多出来CTGNet的2-3跳左右路由以外，和之前CN2 GIA的路由看起来没多少差别了。但是CTGNet网内偶尔会出现莫名其妙的延迟增加情况，体现在香港地区CTGNet网内两跳路由之间延迟增加15-20ms，这个问题属于偶发。

p.s. 中国电信澳门的4G/5G用户在访问中国内地的资源时，流量会通过CTGNet走CN2 GIA至国内。

# Extra

两张网在常见的地区以外，骨干都较小。另外新疆有两种CN2，一种与一般国内CN2无差异，另一种有独立国际出口，但国内营运商访问过墙（被视作境外PoP，这一点可以在电信国际的looking glass页面看到），路由也较为奇葩，如上海访问可能先绕行广东再到北京等等。

CN2与联通之间有互连，上海、广州、北京、香港都有。其中香港互连只跑回国流量。其他互连点仅在GIA路由使用，GT线路仍需经过163。

上海电信101.88.0.0/13段，实际上为163、CN2双上游，但在CN2设置了海外禁播、客户禁播。因此海外CN2并无法收到该网段路由，造成如阿里云香港到该网段走其他线路。

# How to: 区分线路是CN2 GT还是CN2 GIA

如前文所述，CN2 GT和CN2 GIA最大的区别在于，前者CN2 GIA使用的国际跨境网关（即前置知识中提到的C-I段）是独立的，而后者是和ChinaNet (163)共享跨境网关，因此通过判断这一点即可区分是CN2 GIA还是CN2 GT。

一般而言由于CN2 GIA的流量会由就近省份的163-CN2接入点进入CN2骨干网，因此从本地向服务器traceroute时，你应该能看到其存在一跳59.43或者202.97的骨干网IP，其所在地址为就近省份的接入点所在地，比如江浙两省去程走南京，湖南电信去程走武汉，重庆电信向部分地区的去程走南京/西安。部分省份如果当地没有163-CN2的peering的话可能会存在直接从北上广进入GIA的情况，比如重庆对于多数路由会一路202.97走163骨干网直到广州进入CN2。因此即便服务器线路是CN2 GIA，但也不代表你本地宽带跟踪路由时一定全程不走202.97，毕竟你自己宽带还是在163网络下。

一个最简单且多数情况下比较有效的判断方法为，如果从本地追踪一个服务器IP的去程，202.97的下一跳IP为类似于59.43.244.*或者59.43.245.*，且该跳处在北上广三地（北京为59.43.246.*)，则大概率去程为CN2 GT。如果本地追踪服务器IP的去程，经过202.97下一跳为59.43.80.* （2023年1月作者注：电信在2022年至现在对163和CN2的国内互联做过多次调整和扩容，CN2 GIA的互联IP也可能不是59.43.80.*的IP段，但一定不会在59.43.244.*/59.43.245.*/北京出口为59.43.246.*之内） 或者甚至没有202.97就直接到达下一跳59.43路由，则去程大概率为CN2 GIA。回程路由反过来同理。

请时刻牢记一点：CN2是电信的，CN2是电信的，CN2是电信的。不要说什么回程三网都不是走CN2 GIA就说这是假的CN2，这个说法是完全错误的！GIA提供到国内其他运营商的流量穿透，因此去移动联通走不走CN2完全取决于上游商家的决定。

中国联通

中国联通目前有3个主要ASN：AS4837（中国联通骨干网），AS10099（中国联通国际，CUG）以及AS9929（中国联通工业互联网，CUII，以前的老网通的骨干，简称A网）

一般家宽客户接入的是4837网络，与电信4134类似。国际出口分为北京、上海、广州三部分。比较常见的路由如北京出口承载多数省份的跨境流量，包含日韩北美欧洲俄罗斯等地区；上海出口承载至东亚/东南亚以及北美圣何塞的跨境流量；广州出口承载至港澳/东南亚/北美（洛杉矶）/欧洲部分地区的流量。

联通对其上游宣告的IP段有一定倾向性调整（这实际上也是流量工程和QoS的一部分），例如，对于部分IP段，联通在日本发给NTT的路由prepend了AS PATH，造成的情况就是对于同时接了NTT和其他网络的服务商（比如甲骨文东京接了NTT和TATA），由于AS PATH长度问题，至联通部分IP段（例如153.3.16.1）是NTT经由上海/北京互联回程，而部分IP段（例如 27.11.128.1） 则被送去了其他网络，出现绕美/高延迟的情况。这一点在联通至新加坡Cogent的互联也能看出来（部分段走新加坡的Cogent直接回到联通网内，部分则绕欧至联通与Cogent的欧洲互联）。

10099（CUG）与电信目前的CTGNet类似，提供至大陆方向的差异化接入，包括CUG（10099->4837）和CUG VIP（10099->9929->4837）

9929为老网通骨干网，现在的CUII，其本身负载低，所以被用于为政企提供高质量网络访问，但是缺点在于。。。这张网的跨境互联端点对比4837较少，而且多数互联的容量并不大。。。现在作为联通对标CN2 GIA的产品销售。

普通4837的报价依据互联地区不同而不同，日本/新加坡可以做到$20/Mbps甚至更低的价格。（但还是贵而且和电信一样是Best Effort），香港比日本/新加坡略高一些，<=$25/Mbps，欧洲地区 <=$5/Mbps。

香港 10099 CN Premium Route (官方名称，实际上就是9929）的报价一般不低于 $55/Mbps。

为了避免有人不相信这个价格，我贴一下TG某老哥咨询联通销售人员拿到的零售报价。本文前面提到的价格没有特别说明的情况下是commit量大的情况下的折扣后的价格。

中国移动

CMCC这张几乎万物都要走香港出口，而且骨干都能疯狂丢包，广州到香港之间延迟能暴涨114514ms的破网有什么记录的必要吗（半恼） 自己拉了根线测一下免得有人BB我黑移动，不过还是得说一句，请不要用广东移动的质量假设其他省份移动的质量，谢谢茄子（摊手

自2022年初开始，随着上海临港出口启用，在日韩购买了CMI IP Transit的ISP/IDC回到国内部分省份移动的流量会经由上海出口承载，延迟对比绕广东会有所降低（比如日本/韩国 -上海 ~33ms）。

移动近期扩容加上上海临港出口启用以后在跨境段（C-I段）上容量有明显富余，部分方向也开始塞了，加上移动祖传负载不均衡，所以体验会有所波动。

目前的主要出口还是广州-香港段，IPv6跨境流量路由大部分会出现绕行上海的情况（即使你处在广东）。

亚太地区（指香港/日本/新加坡）中国移动的IPT价格比较一致，约 $30/Mbps（2023年至2024年5月)。而中国移动CM Premium的价格一般在 $55-$60/Mbps左右（取决于commit的量）

由于近期大批量的CMI带大陆路由的IPT开通，移动至联通/电信的晚高峰跨网质量相对之前明显有所降低，移动广州出口自4月开始已可见晚高峰时期网内有丢包情况出现，且有明显的负载不均衡的情况。

对来自Free Peer（比如PCCW/NTT/Telstra）至国内的流量会有QOS，在量大的情况下，移动会根据来源流量的ASN进行QOS，尖峰时可见在P2P一跳路由（比如NTT-移动的互联路由节点）开始出现高于80%的丢包。你说广移拉万物？建议阅读开头那段话：请不要用广东移动的质量假设其他省份移动的质量。(2024.5) 正因为此类QOS策略，目前市面上常见的“移动优化线路”多数为通过Lumen (f.a.k.a. Level 3, AS3356)所传输回移动，相对目前CMI直接IPT的价格，Lumen-CMI的价格低了一个数量级，但什么时候会被移动橄榄仍是未知数，这类操作的前车之鉴是NTT/PCCW，后者在早一两年前基本全被移动橄榄。(2024.9) 目前在亚太地区到移动有速度的Tier 1 Transit目前就剩下Lumen和最近移动在日本和新加坡新接的TATA（AS6453）了，通过这两个地区的这两家Tier 1至移动网内目前较少遇到限速或QoS拉黑的问题。PCCWG依然比较灵车。

从IX强行从CMI送流量至国内网络会被移动QoS至不超过1Mbps的速度以及高强度丢包，但是某些情况下仍存在偷带宽的可能性。

CMI日本地区现在不提供至电信和联通的穿透，因为容量不够了 (2024.5) CMI日本POP开始恢复提供至国内电信联通的回国方向流量穿透，根据CMI方面的说法，CMI Paid IPT客户可以申请日本地区CMI回程国内电信联通的穿透路由。新加坡和香港也提供三网回国方向流量穿透。但是由于友商投诉和移动网内策略，所有经由CMI回程至电信联通方向的流量会通过上海出口处理，因此即使你在广东电信，流量还是得至少单向绕上海一圈。

2024年11月中国移动香港至国内方向跨境带宽利用率已达到95%，由于跨境段容量拥塞问题移动目前对跨境流量存在高峰期QoS的情况，部分省份即便是访问购买了正价CMI带宽的用户也会遇到严重限速情况（晚高峰10Mbps至100Mbps均可见）。根据监控数据目前晚高峰时期CMI至国内方向可见大约5%左右的丢包。移动侧答复扩容需等待工信部批准，其他容量规划暂无更新。

2024年11月底由于NCP海缆故障影响中国移动至日本和北美方向链路（包括公网和专线传输），目前流量故障转移至经由香港返回国内。

# 关于CMI N2 （AS58807）

和电信一样，移动也在搞CMI N2 (AS58807)，此网络海外回程路由至国内电信部分会走CTGNet（在looking glass测试时，可能由于目前移动没有在该网络宣告路由给CTGNet，测试的结果显示被降级为CN2 GT路由）现在暂时没有了，已有部分大厂签订业务了。依据购买的产品类型，CMIN2的挂牌单价为 $45 – $55+/Mbps（亚太地区），并且不同等级的产品有不同比例的回国带宽限制，例如，对于Premium DIA产品，部分地区至CT/CU方向至多允许30%的比例（即，如果你购买了1Gbps的Premium DIA，最多有300Mbps的带宽可以用来传输至电信或者联通）。

CMIN2的设计计划是独立的网络，与CN2 GIA/CUII 9929类似，但是目前从巨硬已购买的产品来看，CMIN2目前只有海外段是在AS58807之下，例如，从新加坡CMIN2至国内的流量会在新加坡-香港走CMIN2，而到达香港之后走到AS58453的核心再路由至国内9808，目前暂不清楚这种路由之下这部分带宽是预留给了CMIN2还是只是给了高优先级。（2022.09）目前58807已完成与移动国内网AS9808的直接互联，并且部分地区（比如北京移动）已开始上线国际加速服务使用CMIN2承载流量，然而目前的流量只有单向经过CMIN2，路由还没有完全调整完毕。CMIN2实际划分到的跨境带宽（C-I段）其实并不算多，并且移动对于这部分的流量使用要求总体利用率低于 80%。

2023.11: N2 北美地区已上线，提供了到国内三网IPv4和IPv6双栈优化，根据多个商家和实际测试的结果来看，CMI N2至电信联通甚至移动本网都还存在一定的缺路由的情况，表现为接了N2的网络回程至国内部分网络仍需绕行其他transit.

CMIN2 POP点互联和带宽情况

CMCC关于CMI N2的介绍内容

CTGNet (AS23764)/CUG (AS10099) 和 CMI (AS58453)三张网的差异性

三家运营商目前都有趋势将国际客户的IPT业务转移至自身的国际网络下，但是三家的国际网络资源略有差异。

对于电信和联通，CTGNet和CUG提供的包括对客户的IPT接入以及差异化产品（例如普通IPT：CTGNet给到163，而10099给到4837；而对于精品IPT（Premium IP Transit），CTGNet给到的是原有的CN2 GIA产品，CUG给到的则是联通A网9929。这一点也可以从现有路由能看出来。此外，CTGNet和CUG也为两家运营商在海外的移动客户提供网络接入（例如CUniq和CTMO/CTexcel），并且两张网络也用于对应的国内CN2/9929精品网客户就近访问海外资源。CTGNet和CUG目前并不接管两家运营商全部的出海流量。

而对于移动，AS58453 CMI则是国内移动AS9808客户公网跨境的几乎唯一方向，并且移动的海外精品网访问接入是由AS58807来负责的，与电信CTGNet和联通CUG的角色上有较大的区别。

2024.07：中国电信国内4134大网于7月份开始停止接收来自联通方面的国际客户路由（即来自10099及其客户的路由），此举导致原有通过只拉CUG便能做到联通电信都能直连的操作成为了不可能，除极少数路由以外，4134-4837-10099/4134-9929-10099的走法成为了过去式，现在必须购买电信的互联才能使得国内电信流量去程拉直。8月联通也开始对等操作，拒收了来自电信CTG和CN2国际客户的路由，影响4837-23764/4837-4809的路由，CTG对此的解决方案为在香港购买了4837的10G带宽，并将一些路由在此端口上发送给联通4837大网作为“客户路由”来拉直4837-23764的访问（从路由跟踪看到的 219.158.33.38 即为CTGNet与联通的互联PtP）。

这次双方的“竞合”操作实际影响的还有双方香港的移动运营商业务（CUniq/CTHK)，由于双方国内拒收去程路由，中国电信香港(CTHK)访问国内联通网络，或者CUniq访问国内电信网络时，国内-香港方向的去程路由会绕行欧美（比如4837-1299-23764-CTHK/4134-3257-10099 CUniq)，导致延迟大增。为什么不说移动呢，因为移动去CTHK的流量甚至会喜提绕南非环球游，而且电联不待见移动是早就已知的事情了。

一些题外话/图一乐的小道消息

• CN2变为现在CTGNet接入的一部分原因是，在2020年左右，北美的部分CN2 GT/GIA双持的客户，通过在GIA的端口上宣告IP段，回程走CN2 GT端口的方式，可以使得回程流量变为CN2 GIA，这是因为电信CN2网内区分走GT和GIA路由的方式是根据4809收到的路由端口和类型决定的。当时这么做的商家包括C3（Zenlayer），Hostspace，Krypt (iON)，因此这些商家后面看到的ICMP CN2 GT而TCP/UDP走163也是电信故意而为之。
• CTGNet *有可能* 部分接管了CN2的跨境段，目前可以观测到CTGNet的部分骨干IP出现在了国内部分。大佬的推测是可能在CN2的骨干上再跑了个MPLS
• CN2 （AS4809）到PCCW的互联 *有可能* 会被拔线，转由经CTGNet至PCCW，后者拥有100G互联。
• CUG 10099在HKIX的端口曾被长时间”偷流量“，即通过强制指定下一跳路由的形式，将国内流量经由CUG的路由器送至联通骨干再到国内。目前已有QoS。
• CMI有一位非常不负责任的销售，只会推产品而不认真处理客户问题
• CMI对于没有购买其IPT业务但是通过其上游（比如PCCW/NTT）送流量进来的网络，在流量较大（数百Mbps）的时候会触发QoS，销售会先联系你让你购买CMI的IPT带宽业务，但如果你不买，你可能会被移动拉进黑名单（按ASN），此时在互联点会出现严重丢包。

结尾：本文修订记录

修订记录从4月开始记录（主要是懒得翻之前的修改历史了）

2024年12月2日：CMI跨境段容量相关

2024年9月9日：CUG/CTG国内穿透相关，CUG IX流量相关，CMI与Tier 1流量相关信息更新

2024年5月7日：CMI牌价和日本POP穿透策略更新

2023年8月1日：部分信息更新

2022年9月22日：修订CMIN2至CMNET网络互联情况

2022年9月17日：增加对163扩容信息补充

2022年9月6日：增加对CMIN2的海外互联和带宽信息补充

2022年7月12日：补充CMIN2的部分信息（毕竟CMI公开发布此产品了）

2022年5月16日：增加对CMIN2的部分信息补充

2022年4月22日：更新中国移动CMI网络质量状况

2022年4月14日：增加对运营商报价的说明，附图更新中国联通IPT零售报价

然而最近一两年国内个人站的环境越来越难受，先是之前备案的手机号注销，现在要更新备案信息又要各种证件上传各种麻烦导致现在备案处于随时会被注销的状态，再想到在国内服务器的各种1M2M小水管实在难以忍受，索性选择了注销备案以后把所有东西都搬到香港或者美国的机器上去了。

这个博客也是被搬的对象之一。

搬的时候其实很简单，毕竟之前全部hexo静态化以后其实就只有一堆html和css了，然而不知道怎么脑子一抽，万一哪天想瞎写点东西了呢，反正都已经放到香港的主机上了，这机器虽然带宽比之前也大了没多少，但好在能用，更新什么的也不再是个麻烦事，于是翻遍整个硬盘把两三年前的博客备份找了出来，重新拿wordpress给弄了一遍。

也就是你现在看到的这样了，一切回到17年18年左右的样子。

其实想一想过去三年工作也好生活也好还是有不少东西值得记录的，也有一些“不涉及工作内容”的技术是可以分享的，但愿这次搞完以后后面有时间的时候可以好好记录一下吧。

Updated @ Nov 10,2019

环境

1. 有条件的情况下，请做到生产环境和测试/开发环境隔离
   应该没人会希望自己修改测试环境的时候把生产环境玩炸了（
2. 建议使用Docker/CGroup等容器化方案来部署你的环境
   这些容器技术非常方便你管理使用的环境和数据内容，也方便后期打包维护迁移

系统层面

1. 选择一个LTS版本作为你稳定的生产环境和测试环境，非LTS版作为你的折腾环境
   • LTS版本的系统提供更长时间的支持，至少在有效期内你的系统层面包含的软件包所产生的BUG会有相应的团队及时做更新。
   • 非LTS版本一般表示用于开发和测试用途，系统在这段期间可能会有所修改和调整，甚至大的软件包变更，相对LTS版本会有所不稳定，而且支持期更短。
2. Ubuntu Server/CentOS/Debian 甚至Arch，使用哪个系统作为的发行版作为服务端的系统并没有什么不同，只是相对而言，Debian系（含Ubuntu）等其他发行版所包含的软件版本，会比RHEL系（CentOS类）所包含的软件版本要更新一些
   • 虽然旧即是稳定，但我想了想应该没人会期望在9102年还在用4.4版本连C++11都支持不全的GCC去编译一个C++的代码的
   • 但也不代表全新就是正义，大多数新版本软件包在投入生产环境使用之前经过一段时间的稳定性验证是非常必要的
3. 请定期关注Linux Kernel的更新，例如最近几个月内的TCP MSS的DOS攻击，以及各种内核层面例如UAF（Use After Free）类问题导致的本地提权漏洞，这些需要你及时更新服务端的内核补丁，以保证正常安全运行

维护和软件

1. SSH
   • 鉴于目前全世界24小时扫描爆破SSH 22端口的主机很多，请及时修改SSH默认端口22为其他端口
   • 如果能禁用密码登录，强制使用ssh key登录，那就更好了 参考这里
   • 当然你也可以使用基于ChallengeAuthentication的2FA认证，比如Google Authenticator (英文网页)
   • 对于身处中国大陆的用户，非常不建议使用SSH直连境外22端口，也不建议直接使用SSH协议从服务端向国内传送大量数据，因为某个不可描述但众人皆知的东西。
2. 请配置自动更新
   • 软件包每隔一段时间会有新版本发布来修正一些特定的问题，因此除非你对某个版本的软件有特别的依赖，否则对于一个LTS系统而言，建议自动更新软件包以修正潜在的问题
   • Ubuntu下有 unattended-upgrades 可以帮你做到，其他发行版应该也会有
3. 请使用最小权限原则执行程序和脚本
   • 我知道很多人（包括我自己）都是很喜欢用root直接去做一些事情的
   • 但是出于安全角度考虑依然建议使用特定账户运行特定脚本/程序，以做到最小权限原则
   • 为什么？参考服务器侧配置不当，多网站用户共享同一个user identity导致其中一个网站被黑以后，其他同用户下的网站一同被篡改的类似事件
4. 请关注系统的负载和资源使用
   • 这个应该不用多说吧，在运行的程序在多少任务量的情况下，应该吃掉多少资源产生多少负载，作为开发应该需要有一个观念
   • 及时的监控告警可以帮你发现潜在的很多问题，比如应用BUG

数据

1. 请务必勤备份，即便你在使用云服务等号称N个9加N份冗余备份的场景
   • 你永远不知道下一个前沿数控事件会不会发生在自己身上
2. 数据库一类的软件，请保持在仅能从内网或者本机自身访问
   • 即使你设置了1145141919810个字符长度的密码也不要开放公网直接访问
   • 已经有过不少3306 (MySQL) 或者 27017 (MongoDB) 被扫描爆破导致数据全丢的血泪教训了
   • 大多数数据库软件的验证授权，在默认配置下是明文鉴权，这意味着中间网络设备是可以看到你用于认证的用户名和密码，以及后面操作产生的数据的
   • 即便是测试环境一定要远程访问数据库，也建议通过加密隧道转发，并配置好访问策略（ACL）

本文所描述的安装方式已经过时（2019年3月），你可能需要参考别的资料

此外，wine-devel仅建议在开发环境下使用，生产环境有另一个版本的wine

由于自己服务器的应用栈都是Linux系，而有些时候又不得不跑一些Windows下的应用程序（比如一些莫名其妙的类库、Windows下的一些奇奇怪怪的程序），因此需要安装wine，而目前在google搜到的都是一些陈芝麻烂谷子的不知道多少年前出来的东西，在当前环境压根用不了，所以写一篇短文记录下。

首先，如果你用Google搜“Ubuntu wine”的话，一篇2017年的文章会告诉你这么做：

1、安装源

      sudo add-apt-repository ppa:wine/wine-builds

      sudo apt-get update

2、安装wine

     sudo apt-get install –install-recommends wine-staging

     sudo apt-get install winehq-staging

3、卸载wine

     1).卸载wine主程序，在终端里输入：

       sudo apt-get remove –purge wine

     2).然后删除wine的目录文件：

       rm -r ~/.wine

     3).卸载残留不用的软件包：

       sudo apt-get autoremove

4、终端中输入wine，检测是否安装完成。

https://launchpad.net/~wine/+archive/ubuntu/wine-builds

!!! PLEASE NOTE THAT THIS REPOSITORY IS DEPRECATED !!!

For more information, please see:

https://www.winehq.org/pipermail/wine-devel/2017-March/117104.html

The following commands can be used to add the new repository:

wget https://dl.winehq.org/wine-builds/Release.key
sudo apt-key add Release.key
sudo apt-add-repository ‘https://dl.winehq.org/wine-builds/ubuntu/‘

 wget https://dl.winehq.org/wine-builds/Release.key && sudo apt-key add Release.key

sudo apt-add-repository ‘https://dl.winehq.org/wine-builds/ubuntu/’

dpkg –add-architecture i386

apt update && apt install wine-devel

sudo vim /etc/profile

添加下面一行：

export PATH=/opt/wine-devel/bin:/opt/wine-devel:$PATH

:wq保存