TG DC 是一个非常神秘的存在,TG 官方几乎未披露任何与其相关的内容,网上的各种文章其内容甚至互相冲突或残缺不齐。
似乎在实践中,很难见到来自 DC2、3 的活人:

"许多人曾在大群通过 @Sean_bot 查询其所在数据中心, 存留到聊天记录里.
于是记者通过全局搜索 "My Data Center is", 统计, 找到 3 处 DC.

1. 迈阿密
4. 阿姆斯特丹
5. 新加坡

当记者试图全局搜索 DC2, DC3 时, 却得不到任何结果. 神秘的 DC2, DC3身处何处? 它们真的存在吗?

...

结论: (update: 部分结论已被推翻)
凡 tg 用户, 皆归 DC1, 4, 5;
DC2 存在, 且为 MTProto API 所用;
尚未出现与 DC3 相关的证据/报道, 暂时认为 DC3 不存在"


然而事实真的是这样吗?

了解 Bot 常用的获取 DC ID 的方式

@WooMaiBot / @Sean_bot 与网页:https://lab.best33.com/telegram-datacenter 都是 TG 用户常见的查询自己或某用户所在 DC 的方法。
不难发现,这些 Bot 都基于一个特点:通过用户头像存储的位置来判断用户所在 DC。
原来,TG 共有 DC1-5 5个数据中心(暂时称为数据中心),一位用户存在于一个特定的数据中心中,其上传的媒体文件包括头像将存储在这个 DC,其他用户若要读取则须先连接该 DC,并从该 DC 上读取该文件。
显然,通过解析该 DC IP 的位置就能轻松拿到用户所在 DC。
TG 正好又提供 t.me 服务,这是一种在浏览器中打开就能直接获取到 Chat / Message 详情的链接,若查询目标内包含媒体文件,则会通过 Web CDN 下载该文件以便将其显示在浏览器中。
通过打开 t.me/HertzYang,我们不难发现头像是从 cdn5.telesco.pe 下载的。
再观察几个 DC1、DC4 的用户,我们也可以发现头像分别是从 cdn1、cdn4 下载的。
这是一个非常简单的 DC 读取方法,只需要将用户名拼接在 URL 并访问、解析即可获取结果。
因此,通过请求 t.me 并解析 HTML,读取头像链接并判断其域名(cdn1、2、3、4、5)成为了 TG 上 DC 读取 Bot 的常见读取方法。
所以,你也会发现这些 Bot 会有 用户必须有用户名 + 用户必须有公开头像 的要求。

这么做真的准确吗?

不准确!


上文中提到了在某大群搜索 DC2、3 均无结果,因此得出了 DC2、3 不存在或用户无法使用的结论。
这么做需要有一个非常重要的基础:读取 DC 的 Bot 输出的结果可信、准确。
然而上文也提到这些 Bot 都是通过 Web CDN 域名判别用户的,那么有没有例外呢?
答案就藏在 DC2、3 的用户头像里:
@flowinglight <- 这是一个人畜无害的 DC3 用户。
打开 pyrogram,获取该用户的详情:
pyrogram.types.User(..., username='flowinglight', DC_id=3, ...)

但是上述 Bot 都认为这是个 DC1 用户:

干物妹!小霾: @flowinglight 所在数据中心为: DC1
该数据中心位于 迈阿密, 佛罗里达州, 美国
了解更多


继续深入,我们可以发现 pyrogram 的 DC_id 来源也是用户头像位置DC_id=chat_photo.DC_id

问题来了:两边都是同样的原理,为何出现了不同的结果?

首先明确:该用户实际上的确属于 DC3,头像也在 DC3。
那么为什么这些 Bot 会认为该用户位于 DC1 呢?
回到这些 Bot 的原理部分,我们不难发现他们是从 t.me 中获取的 Web CDN 链接进行判别的。
多次试验可以发现,t.me 中 DC2、3 的用户的头像是从 CDN1、4 获取的,并非其应在的 CDN2、3。
因此上面的这些 Bot 全军覆没,全部给出了错误的答案。
那没为什么没有 CDN2、3 呢,DC2、3 用户是真的神秘而少见吗?

首先,我们需要明确一点:存在 DC2、3 用户,但这类用户确实属于少数(约占 TG 全体用户 0.1% - 1.0%)
上述数据是我通过准确的方法检索数个国内外大群得出的结果,一般国内群组约为 0.1%,国外群组约为 1.0%。在这 0.1% - 1.0% 中又有 95% 是 DC2 用户。
也就是说 DC3 用户是 TG 国宝级用户,约占 TG 用户总量的 0.005% - 0.05%。

上述 Bot 的不准确检测方案无法输出 DC2、3 的结果,因此导致 TG 上似乎压根不存在 DC2、3 的用户,以至于让部分人怀疑 DC2、3 根本不存在。

那么 DC2、DC3 究竟是什么呢?

通过简单的 mtr 可以发现,DC2、DC4 地理位置相同(欧洲荷兰),DC1、DC3 地理位置相同(美国迈阿密)。

TG 实际上还有一个 Web 网页版,通过 Websocket 包装后的 MTProto 与 Telegram DC 间接通信。

用户 <-> Websocket Forwarder <-> MTProto Server

Websocket Forwarder 是一个类似于 Bot API 的存在,本身独立于 MTProto Server。
网页版 TG 有 zws{1-5}.web.telegram.org 共 5 个域名。
然而,zws1、3 与 zws 2、4 的解析 IP 完全一致
因此可以合理推断出:
DC2 为 DC4 的附属 DC,DC3 为 DC1 的附属 DC
DC2、3 均无 Web CDN 能力,t.me 中 DC2、3 用户头像将由其上级 DC 的 Web CDN 提供
DC2、3 注册条件与上级 DC 相同,但只有部分情况才会将用户转入附属 DC 注册(个人推测是上级 DC 某一时间段内注册用户过多时就会发给附属 DC)


这可以解释:
为什么 t.me 中 DC2、3 用户需要到 CDN1、4 去读取头像 / 为什么 DC2、3 用户也是连接 DC1、4 的 Websocket
因为两两 DC 之间为附属关系,子 DC 部分功能残缺,故向上请求。
为什么 DC2、3 用户非常少见
DC2、3 作为附属 DC 并不直接处理注册请求,与其他3个 DC 地位不平等,因此人很少。
为什么 DC5 经常炸
可以合理推测 主附 DC 有互补能力,可作为灾备节点,因此 DC1、4 爆炸时用户可以切换到 DC2、3,而 DC5 无附属节点,一挂就真的挂了,因此表现出非常不稳定的现象。
或许这也可以看出 TG 团队并不重视亚洲地区。

另外 TG 还在文档中声明 Telegram 会自动在用户长时间在其他位置登陆后自动更换该用户所在 DC,甚至还预留了一个错误码。
然而实践中,我从未见过任何 TG DC 变更的实例,咨询多位朋友也从未见过。
因此我认为这块功能 TG 没有做,或者至少没有投入使用。(毕竟换 DC 确实太麻烦了,所有媒体文件还得重新传,特别耗流量。)
如果你认识这样的用户,也欢迎联系我。

所以我在哪个 DC???

我做了一个可以正确读取 DC2、3 的 DC 查询机器人:@FindRealDCBot

后记

时间仓促,并且有许多内容基于合理推测,无法 100% 保证正确性。
如有错误,欢迎勘误:[email protected] 或者直接新开一篇文章怼我
感谢 oott123(就是上文网页版 DC 查询器的制作者)给我的重大线索(DC2、3 和 CDN1、4 的事)。