Telegram 技术架构调研

调研日期：2026-10-06（UTC）报告语言：中文，技术术语保留英文原文信息可信度分级：✅ 官方确认（Telegram 官方文档 / 官方博客 / 官方 GitHub 仓库）｜ 📄 学界分析（同行评审论文、预印本）｜ 📊 媒体/二手（新闻、社区文档，需交叉验证）｜ 💬 社区推测（未证实，仅供参考）

1. 整体架构与设计哲学

1.1 中心化架构：有意为之的非联邦设计

Telegram 采用集中式客户端-服务器（client-server）架构，而非联邦式（federated，如 Matrix / XMPP / Email）或纯 P2P 架构。所有客户端通过自研的 MTProto 协议连接 Telegram 自营的数据中心（DC）集群；服务器端代码完全闭源，只有客户端开源。

这一选择的直接后果是：Telegram 可以提供无缝的多设备同步与云端存储——用户在新设备登录后可立即获得全部聊天记录，无需像 Signal 那样做设备间迁移。这是其产品哲学的核心：官方 FAQ 明确回答"为什么不把所有聊天都做成 secret（端到端加密）"——因为 E2E 范式下"在新设备上恢复聊天记录没有优雅的解决方案"，而可靠备份是大众市场通讯软件的必备功能。Telegram 选择了第三条路：Cloud Chats（服务端可读的加密云存储）+ Secret Chats（可选的 E2E），并认为这"是对大众流行应用而言目前最安全的方案"（✅ 官方：telegram.org/faq，2026-10-06 经 archive.org 摘录读取）。

代价同样明确：默认聊天的明文对 Telegram 服务器可见（传输层 MTProto 加密、存储时服务器持有解密能力），其隐私保证建立在"分布式跨国基础设施 + 密钥分片"之上，而非数学上的不可读。官方称：云聊天数据分散存储在全球多个数据中心，由不同法域的法律实体控制，解密密钥被切分且从不与所保护的数据存放在同一地点，因此需要多个法域的法院命令才能调取数据；并宣称"至今已向第三方（包括政府）披露了 0 字节用户消息"（✅ 官方：telegram.org/faq）。

1.2 多数据中心与账号分片

Telegram 在全球运营 5 个生产数据中心（DC1–DC5），客户端通过 help.getNearestDc 等机制获知 DC 拓扑（✅ 官方 TL schema 有 DC 相关方法；具体位置为 💬 社区测定）：

DC	社区测定位置	IPv4（社区文档）
DC1 / DC3	美国迈阿密（DC3 被指为 DC1 别名）	149.154.175.x
DC2 / DC4	荷兰阿姆斯特丹	149.154.167.x
DC5	新加坡	91.108.56.x

来源：📊 Pyrofork 社区文档（2026 年读取）、GIGAZINE 2026-08-15 对社区开发者 Coxxs 调查的报道。Telegram 官方从未公布 DC 物理位置，位置信息属社区通过 IP 归属与延迟测定的推测。

关键的架构特性是账号与 DC 的强绑定（sharding by account）：用户注册时被分配到一个 DC，此后该账号的"家 DC"（home DC）不变；若客户端连到错误的 DC，服务器返回 *_MIGRATE_X 错误（如 PHONE_MIGRATE_2），客户端自动迁移（✅ 官方 MTProto 文档与错误码体系）。媒体文件可分布在不同 DC（FILE_MIGRATE_X 只改变媒体 DC）。这种设计使故障域按账号分区——2026-09-08 DC5（新加坡）故障导致亚太区大规模中断而其他四个 DC 正常（📊 smebuddies / cryptobriefing 2026-09 报道），以及 2018-03-29 欧洲宕机时 Durov 称"美洲与东亚未受影响"（📊 SiliconANGLE 2018-03-29），都印证了分区式多集群架构。

1.3 为何不做默认端到端加密

官方给出的理由有三层（✅ 官方：telegram.org/faq；core.telegram.org/techfaq）：

功能权衡：E2E 与云同步、多设备、无缝备份互斥；Telegram 禁用系统级备份，转而提供"集成的安全备份"即 Cloud Chats。
社会安全考量：让 Telegram 广泛流行而非仅限活动家使用，“单纯使用 Telegram 这一事实本身不会让用户成为加强监控的目标”。
信任模型：Telegram 认为其"分布式跨法域加密云存储"比 WhatsApp/Viber 式的"可解密备份"更安全（这是一家之言，学界多不认同，见第 10 节）。

2. MTProto 协议

2.1 协议分层

MTProto 在官方文档中被描述为三个"虚拟独立"的组件（✅ 官方：core.telegram.org/mtproto，2026-10-06 live 读取）：

高层组件（High-level component / RPC Query Language）：API 查询与响应的二进制消息定义，对应 OSI L7；类型语言为 TL（Type Language）（L6）。
加密/授权层（Cryptographic / authorization layer）：消息加密，对应 OSI L5（会话）。
传输组件（Transport component）：承载于 TCP / HTTP / HTTPS / WebSocket / WSS / UDP 之上；其下还有 MTProto 自己的传输封装协议（abridged / intermediate / padded intermediate / full，对应 L4.3）与可选的混淆层（obfuscation，L4.2）。

关键抽象：会话（session）附着于客户端应用实例而非单个连接——一个会话可同时开启多个连接，请求的响应可经任一连接返回（但绝不会经由属于其他会话的连接）。这为并行文件分片下载、断线重连提供了协议级支持。

2.2 MTProto 2.0 相对 1.0 的改进

自客户端 v4.6（2017-12）起主要客户端使用 MTProto 2.0，1.0 已弃用（✅ 官方）。学界总结的实质改进（📄 Miculan & Vitacolonna, arXiv:2012.03141, 2020；✅ 官方 core.telegram.org/api/end-to-end）：

msg_key 计算纳入填充字节：1.0 中 msg_key（认证标签）在填充之前计算，导致 Jakobsen & Orlandi 的理论 CCA 攻击（📄 eprint 2015/1177）；2.0 中 msg_key = SHA-256(auth_key 片段 32 字节 + 明文含 12…1024 随机填充) 的中间 128 位。
SHA-256 取代 SHA-1：1.0 用 SHA-1 计算 msg_key；2.0 全面使用 SHA-256（SHA-1 仅保留在与安全无关的场景：auth_key_id、DH 指纹）。
密钥派生绑定密钥材料：2.0 的 AES 密钥/IV 派生中混入 auth_key（或秘密聊天密钥）的不同片段，且用 x=0/x=64（云聊天）或 x=0/x=8（秘密聊天）区分通信方向，使两个方向永不共享同一 AES 密钥。
填充长度 12…1024 字节（1.0 为 0…15），增强流量分析抗性。

官方声称 MTProto 2.0 满足 IND-CCA（✅ 官方 techfaq：“MTProto 2.0 satisfies the conditions for indistinguishability under chosen ciphertext attack”）。但学界指出这只是 Telegram 的自我宣称：2022 年 IEEE S&P 的 Distinguished Paper “Four Attacks and a Proof for Telegram”（Albrecht 等，📄）证明的是**“轻微修改版”协议在双向安全信道模型下的安全性，且依赖"未经充分研究的假设"；同时给出了针对实际部署版本**的两个攻击（含一个实用的重排序攻击）、三个官方客户端的计时侧信道攻击，以及针对服务器密钥交换实现的 MitM 攻击（后两者链式结合可恢复明文）。结论是：MTProto 2.0 的记录层"大致"安全，但密钥交换与实现细节存在实质弱点。

2.3 授权密钥生成（Authorization Key）

客户端首次运行时与每个 DC 执行一次 2048-bit Diffie-Hellman 握手，生成长期 auth_key（256 字节），此后几乎不再更换（✅ 官方：core.telegram.org/mtproto；📄 arXiv:2012.03141）：

req_pq_multi：客户端发 16 字节 nonce；服务器回 server_nonce、约 63-bit 合数 pq（DoS 防护挑战）及服务器 RSA 公钥指纹列表。
req_DH_params：客户端分解 pq（Pollard Rho），生成 256-bit new_nonce，用服务器 RSA 公钥以 RSA-OAEP+ 变体加密 (pq, p, q, nonce, server_nonce, new_nonce)；服务器回 server_DH_params_ok（AES-256-IGE 加密，密钥由 new_nonce/server_nonce 经 SHA-1 派生）。
set_client_DH_params：客户端验证 DH 参数后发送 g_b，双方得到 auth_key = g^(ab) mod p；服务器回 dh_gen_ok。

安全校验（✅ 官方：core.telegram.org/mtproto/security_guidelines，2026-10-06 live 读取）极为细致：客户端必须验证 p 为安全素数（p 与 (p-1)/2 皆素数，2^2047 < p < 2^2048），g ∈ {2,…,7} 且用二次互反律验证其生成 (p-1)/2 阶子群；g_a/g_b 须落在 [2^{2048-64}, p − 2^{2048-64}]；必须使用密码学安全 PRNG（可混入服务器提供的熵，但绝不能单独使用）。服务器身份认证依赖**客户端内嵌的 RSA 公钥（TOF

U 信任模型）**（✅ 官方 techfaq）。

2.4 加密原语：AES-IGE / AES-CTR 的使用

云聊天消息体：AES-256-IGE（Infinite Garble Extension）加密；每消息的 AES 密钥/IV 由 msg_key 与 auth_key 片段经两次 SHA-256 派生（sha256_a/sha256_b 拼接），x 区分方向。官方辩护 IGE 的选择：IGE 的已知"块自适应 CPA"攻击要求同一密钥用于多条消息，而 MTProto 的密钥依赖消息内容、消息必须完整形成后才能加密；非自适应 CPA 下 IGE 与 CBC 同等安全（✅ 官方 techfaq）。
秘密聊天文件/通话媒体：AES-256-IGE（文件）与 AES-CTR（通话媒体包，见 8.2）。
加密 CDN：AES-256-CTR，每文件独立密钥（✅ 官方 techfaq）。
传输混淆（obfuscation）：默认对全部传输包做 AES-128-CTR 混淆，但密钥/IV 置于流首明文传输——明确不提供密码学保护，仅用于反流量指纹/反审查（📄 “Four Attacks” 论文；✅ 官方文档列为可选传输特性）。

2.5 消息序号、会话与盐

每个加密消息含：64-bit server_salt（服务端定期轮换，防重放与时钟偏移攻击）、64-bit session_id、64-bit msg_id（≈ unix_time × 2^32，单调递增；客户端发出为偶数、服务端为奇数）、32-bit seq_no（内容消息为偶数序列，纯 ack 不占号）。接收方校验：msg_key 匹配、时间窗口（未来 30 秒 / 过去 300 秒之外丢弃）、最近 N 个 msg_id 重放窗口、会话 ID 一致；任何校验失败必须静默丢弃，且错误响应必须与 msg_key 校验失败的响应无差别（防计时预言机）（✅ 官方 security_guidelines）。

2.6 混淆传输与 MTProxy

传输混淆：obfuscated2 协议——客户端生成随机 64 字节前导（含 AES-CTR 密钥/IV），使流量无固定特征；dd 前缀密钥启用随机填充、ee 前缀启用 fake-TLS（ClientHello 字节串仿冒 Chrome，由 TDLib 的 TlsInit.cpp 定义）（📊 社区对 TDLib 源码的分析；wzgram 提交记录）。

MTProxy（✅ 官方项目 github.com/TelegramMessenger/MTProxy；2018 年为应对俄罗斯封锁推出）：客户端把代理当作"伪服务器"连接，说 MTProto 方言；代理只做加密包的中继，不解密内容（📊 Hacker News 社区技术讨论 2018）。代理运营者可配置推广频道（v1 协议支持，v2 去除广告标签）。本质上是"协议内代理"而非 VPN：只代理 Telegram 流量、开销低、配合混淆对抗 DPI。

3. 服务端基础设施

3.1 技术栈：公开信息极少

服务端完全闭源，官方未披露语言、数据库或框架。这是 Telegram 架构调研中最大的黑箱（✅ 可验证事实：无任何官方服务端代码或架构白皮书）。
可推断的线索：客户端/TDLib/Bot API 服务器均为 C++17（✅ 官方 tdlib/td README），依赖 OpenSSL、zlib；TDLib 内含 tdactor（actor 并发模型）、tddb（SQLite 本地存储）。💬 社区普遍推测服务端亦以 C/C++ 自研为主（Durov 兄弟的 VK 技术背景），但无官方来源证实，本报告不将其作为事实。
团队规模官方未披露；💬 外界常引用"约 30 名核心工程师"，无可靠官方出处，不采信。

3.2 数据中心与媒体 CDN

5 DC 分区架构见 1.2。账号级分片 + 媒体可跨 DC。
加密 CDN（✅ 官方 techfaq）：Telegram 4.2（2017）起，对 10 万+ 成员的公开频道媒体启用第三方 CDN 缓存节点，部署于"Telegram 不愿自建服务器但流量巨大"的地区（如土耳其、印尼、南美、印度、伊朗、伊拉克）。每文件用唯一密钥 AES-256-CTR 加密，密钥仅主 MTProto 服务器与授权客户端持有；客户端按哈希验签；原始文件始终在 Telegram 服务器；CDN 只缓存加密副本，故障时回源；私密数据永不进入 CDN。

3.3 大文件存储与分片下载

文件分片上传：upload.saveFilePart 按 part 切片上传（📊 社区文档称常用 512 KiB/片；官方 api/files 文档定义分片机制）。
单文件上限：免费用户 2 GB（📄 TGDataset, arXiv:2303.05345, 2023/2025）；techfaq 称协议支持"单个文件可达 4 GB"（✅ 官方，对应 Premium 档）。
MTProto 协议原生支持多连接并行下载（✅ 官方 mtproto 文档：“Several connections to a server may be open”），下载可并行多 TCP 连接；FILE_MIGRATE_X 指示媒体所在 DC。
Bot API 公有端点限制上传 50 MB / 下载 20 MB，自建 --local 模式可上传 2000 MB、下载不限（✅ 官方 tdlib/telegram-bot-api README）。

3.4 消息队列与推送

Telegram 没有传统意义上的消息队列中间件概念对外暴露；其"队列"即** MTProto 的更新（updates）推送机制**：客户端与服务器保持长连接，服务器通过该连接主动推送 update；离线期间的消息由服务器暂存，重连后客户端用 updates.getDifference 拉取差量（✅ 官方 api/updates）。移动端后台时依赖系统推送通道（APNs/FCM）唤醒——此为 💬 行业常识，官方未在文档中详述推送网关实现。

3.5 规模数字

指标	数值	来源与可信度
MAU	10 亿（2025 年突破）	✅ 官方 telegram.org/press（2026-10-06 live）
公司总部	迪拜	✅ 官方 telegram.org/press
DAU / 日消息	约 4.5 亿 / 150 亿条	📊 二手汇总（reborndigital.ca），历史序列可信（TechCrunch 2015-09 报道 120 亿/日；2016 年 150 亿/日）
盈利	2024-12 首次盈利：收入 >10 亿美元，利润 5.47 亿美元	📊 Durov 频道声明的二手转述
峰值并发	官方未披露	—

4. 数据模型与同步

4.1 云聊天 vs 秘密聊天的存储差异

云聊天（Cloud chats）：消息经 MTProto 加密传输后，以服务器可解密的形式存入 Telegram 云端，全设备同步、换机恢复（✅ 官方 faq/techfaq）。代价是服务器持有解密能力。
秘密聊天（Secret chats）：E2E 加密，密钥只存在于两端设备；不进云端：服务器仅维护一个临时 qts 事件队列用于投递，客户端确认接收（messages.receivedQueue）或 7 天后即删除；与特定**授权密钥（设备）**绑定而非账号，换设备不可迁移（✅ 官方 core.telegram.org/api/end-to-end）。

4.2 多设备同步：updates / pts / qts / seq

Telegram 的同步是游标式差量同步而非向量时钟（✅ 官方 core.telegram.org/api/updates）：

pts：message box 事件序列（私聊/小群消息的新增、编辑、删除等均消耗 pts）；
qts：秘密聊天临时队列序列；
seq + date：通用更新序列；
每个频道/超级群有独立的 pts（updateChannelTooLong / updates.getChannelDifference）。

应用规则：local_pts + pts_count == pts 方可应用更新；大于则为重复（忽略）；小于则出现缺口，必须调用 updates.getDifference 补齐。登录时先 updates.getState 取基准；超过 15 分钟无更新应主动拉差量。random_id（客户端生成的 64 位随机数）用于发送去重，服务器回 updateMessageID 绑定正式 msg_id（✅ 官方 TL schema；📊 社区客户端实现文档）。

4.3 已读回执与在线状态

已读：messages.readHistory 标记已读，产生 updateReadHistoryInbox/Outbox；channelFull/chatFull 含 read_inbox_max_id、read_outbox_max_id、unread_count（✅ 官方 api/group-calls 文档中 channelFull 定义，2026-10-06 live 读取）。
频道消息有浏览计数器（view counter），转发副本的浏览也计入（✅ 官方 faq）。
在线状态：API 暴露用户在线/最后上线时间，带隐私粒度控制（“最近上线过"模糊显示）——此为产品级共识，底层 UserStatus/updateUserStatus 机制未在本次调研的官方文档页中逐字验证，记为 📊/💬。

5. 客户端架构

5.1 各端开源情况

官方开源的客户端（✅ 官方 telegram.org/apps 及 GitHub）：Android（DrKLO/Telegram）、iOS（TelegramMessenger/Telegram-iOS）、Desktop（telegramdesktop/tdesktop）、macOS、Web（K/Z 版）——均为 GPL/相应开源许可。服务端闭源是唯一例外。

5.2 TDLib 的设计

TDLib（Telegram Database library）（✅ 官方 github.com/tdlib/td，2026-10-06 live 读取）：

跨平台 C++17 核心，“为构建 Telegram 客户端而生”；支持 Android/iOS/Windows/macOS/Linux/BSD/WebAssembly 等；提供 JSON（C ABI，易于绑定任意语言）、C++、Java（JNI）、.NET 接口。
设计要点：全异步（请求互不阻塞）、网络/加密/本地存储全托管（内嵌 MTProto、TLS、SQLite via tddb）、本地数据用用户提供的密钥加密、保证更新有序投递、弱网可靠。
内部含 tdactor（actor 并发框架）、tdnet、tdtl（TL 编解码）；JSON 接口遵循语义化版本。
性能背书：官方称在 Telegram Bot API 中"每个 TDLib 实例可处理 43000+ 活跃 bot”。
许可：Boost 1.0（比 GPL 宽松，允许闭源商用集成）。

5.3 第三方客户端生态

开放的 MTProto + TL schema + 官方客户端源码催生了庞大第三方生态：Telethon、Pyrogram、GramJS、MadelineProto 等库，以及无数改版客户端。第三方客户端必须遵守官方安全指南（✅ 官方要求），且需自行申请 api_id/api_hash。秘密聊天因 E2E 握手复杂，多数第三方库长期缺失支持（如 Telethon 官方版至今不支持，由社区包 telethon-secret-chat 补足——📊 GitHub 社区项目）。

6. 群组与频道架构

6.1 类型与规模

基础群（chat）：≤200 成员；超级群（supergroup）：上限 200,000 成员；频道（channel/broadcast）：订阅数无上限（✅ 官方 faq；📄 TGDataset）。
在 TL 视角，频道是超级群的特例：仅管理员可发帖、成员列表不可见、帖子署频道名（📊 TDLib 文档对 supergroup 类的描述）。
200k 上限的工程含义：群成员列表、权限、在线数等元数据需要高效的聚合与分页（channelFull.participants_count、online_count 等字段），大群成员列表对普通成员不可见即为 fan-out 优化的一部分。

6.2 fan-out 实现思路

官方未公开 fan-out 的服务端实现细节，以下基于公开协议行为的合理推断（💬 推测，标注）：

频道广播：消息在频道内只存一份，以频道独立的 pts 序列组织；订阅者通过 updateNewChannelMessage 接收，或离线后用 getChannelDifference 按频道 pts 拉取——这是"读时扩散（read-fan-out）“而非"写时复制”，使千万级订阅频道成为可能。
超级群：写扩散给在线成员的长连接 + 离线者走 message box 的 pts 队列；pts_count 批量计数保证缺口检测。
已读/浏览统计：频道用聚合浏览计数器（view counter，转发副本计入）；超级群对大群只显示近似在线数，小群支持"谁已读"（getMessageReadParticipants 类 API 存在，但本次未逐字验证官方文档，记 📊）。

6.3 置顶 / 慢速模式等机制

均为服务端状态 + 更新事件实现（✅ 官方 TL 定义在 2026-10-06 live 读取的 group-calls 文档中可见）：

置顶消息：chatFull/channelFull.pinned_msg_id；
慢速模式：channelFull.slowmode_seconds、slowmode_next_send_date（服务端限频）；
管理员精细权限、部分封禁（partial bans）、阅后即焚 TTL（ttl_period）均为服务端的 per-chat/per-user 状态机，经 updates 推送。

7. Bot 生态架构

7.1 中继式架构

Bot 不直连 MTProto：开发者经 HTTPS 调用 api.telegram.org/bot<token>/METHOD，Telegram 的 Bot API 服务器（基于 TDLib，✅ 官方 README）在后端把 HTTPS 翻译为 MTProto 并与 DC 通信。Bot 在协议中是受限的特殊账号：不能发起 secret chat、不能直接看到所有消息（隐私模式），所有流量经 Telegram 服务器中转——这使 Bot 生态天然抗爬、易审计，但也意味着 Bot 无法 E2E（Bot 能看到用户发给它的明文）。

7.2 长轮询 vs Webhook

两种更新投递方式（✅ 官方 core.telegram.org/bots/api；📊 社区生产经验文档）：

	长轮询（getUpdates）	Webhook（setWebhook）
网络要求	仅出站 HTTPS，NAT 后可用	公网 HTTPS 端点（443/80/88/8443）
延迟	长轮询悬挂 ~30–50s，近实时	事件推送，延迟更低
扩展性	单消费者（offset 串行）	可水平扩展、无状态
运维	零入站面	需反代、证书、处理 Telegram 24h 重试风暴

7.3 可自建 Bot API 服务器

官方开源 tdlib/telegram-bot-api（C++，✅ 官方）：--local 模式解锁——上传 2000 MB、下载不限大小、file:// 本地路径直传、webhook 可用纯 HTTP/任意 IP/任意端口、max_webhook_connections 可达 100000。代价是自运维 C++ 服务与磁盘。这是 Telegram"云优先、兼顾重度用户"的典型取舍。

7.4 Mini Apps / WebApp 架构

Telegram Mini Apps（✅ 官方 core.telegram.org/bots/webapps，2026-10-06 index 读取）：

本质是跑在 Telegram 内嵌 WebView 中的 HTML/JS 应用，经 window.Telegram.WebApp JS bridge 获取主题、视口、关闭确认等原生能力；
身份认证：Telegram 向 Mini App 注入 initData（含 user、auth_date 与 hash）；后端必须校验：secret_key = HMAC-SHA256(bot_token, "WebAppData")，再对按字母序拼接的 data-check-string 做 HMAC-SHA256 比对 hash，并检查 auth_date 防重放；
第三方验证：新版支持 Ed25519 signature，验证方只需 bot_id 而不需 bot_token；
架构含义：Mini App 是"以 Bot 为入口、以 Web 为界面、以 Bot token 为信任根"的混合架构，支付经 Bot API（Telegram Stars）闭环。

8. 音视频通话

8.1 一对一通话：E2E 与密钥协商

一对一语音/视频通话为端到端加密（✅ 官方 core.telegram.org/api/end-to-end/video-calls，2026-10-06 live 读取）：

密钥协商：在秘密聊天 DH 基础上的三消息承诺变体——A 先发 g_a_hash = SHA256(g_a)（phone.requestCall），B 回 g_b（phone.acceptCall），A 再发 g_a（phone.confirmCall）；B 校验 SHA256(g_a) == g_a_hash。攻击者只有一次"闭眼"机会，配合 4-emoji 可视化（333 表情池，>33 bit 熵）使 MitM 成功率 < 1e-10（✅ 官方 techfaq）。
媒体加密：开源的 Telegram Voice and Video Call Library 实现"优化版 MTProto 2.0"——注意用 AES-CTR 而非 IGE：msg_key→256-bit aes_key + 128-bit aes_iv，x ∈ {0, 8, 128, 136} 区分方向（outgoing/incoming）× 通道（transport/signaling）；
防重放：每包独立 32-bit seq，接收窗口 64，seq 达 2^30 则中止通话。

8.2 P2P 与中继的选择

双通道：信令（signaling）走 Telegram API（可靠但慢），媒体（transport）走 WebRTC；
P2P 优先：双方直连（ICE 协商）；NAT/防火墙导致失败时回退到 Telegram 的中继服务器（reflectors），按最低延迟选择。中继只转发 E2E 密文，无法解密（✅ 官方文档；📊 MEXC 等二手总结一致）。
客户端设置中有"对通话使用代理/中继"的显式开关（📊 社区文档）。

8.3 群组通话的中继架构

群组通话（voice chat / video chat / livestream）关联群/超级群/频道，一群同一时间只能有一个活跃通话（✅ 官方 api/group-calls）；
默认 WebRTC 发布/订阅；大观众自动切换为 stream mode（服务端把观众从 WebRTC 切到"下载媒体分片"模式以扩展），支持 RTMP 外部推流与服务端录制；
2025-04 起支持 E2E 加密的群组会议（上限 200 人，无需先建群）：官方称采用"blockchain-like 分布式安全"防止秘密加入者，用 4-emoji 验证（✅ 官方 telegram.org/blog/group-calls-made-easy）。其密码学细节官方仅给出概念描述，具体构造未完全公开——记为 ✅（功能存在）/ 💬（内部构造）。

9. 区块链相关：TON

9.1 TON（Gram）项目始末

时间	事件	来源
2018-02 / 2018-03	两轮私募共融资 17 亿美元（约 200 名投资者），开发 TON（Telegram Open Network）与 Gram 代币；原计划公募（上限 20 亿）后取消	📊 CoinDesk / SiliconANGLE
2019-10	SEC 起诉，指控 Gram 为未注册证券发行，获临时限制令	📊 CoinDesk
2020-03-24	纽约南区法官 Kevin Castel 支持初步禁令，禁止发行 Grams	📊 CoinDesk
2020-05-12	Durov 宣布"Telegram 对 TON 的主动参与结束"	📊 CoinDesk / Moscow Times
2020-06-26	和解：1850 万美元民事罚款 + 3 年内返还投资者 70%（约 12.24 亿美元）+ 未来发币需提前 45 天通知 SEC	📊 CoinDesk

9.2 对 Telegram 架构的影响

TON 从未与 MTProto/消息架构在协议层耦合——原设计是应用层集成（客户端内置 Gram 钱包），消息系统本身不依赖链。项目终止后，Telegram 架构未发生链上改造；Telegram 开源了 TON 代码（节点、共识论文、钱包），社区以 The Open Network（TON Foundation / TON Labs 验证者网络）名义独立延续，与 Telegram 无股权与控制关系（📊 CoinDesk）。

9.3 独立发展现状（简述）

TON 作为独立公链持续发展；2026 年出现回潮迹象：Toncoin 更名为 Gram；2026-07-21 Durov 宣布将在 Telegram 全端内置非托管 Gram 钱包（“人类历史上最大规模的非托管钱包 rollout”，目标 10 亿+ MAU），@wallet（The Open Platform 运营的托管 bot，已有 1.5 亿注册用户）并行存在（📊 crypto.news / Cointelegraph / TechBullion，2026-07）。这仍是应用层集成，不改变 MTProto 架构。

10. 工程取舍与对比

10.1 与 Signal / WhatsApp 的关键架构差异

维度	Telegram	Signal	WhatsApp
默认 E2E	❌（仅 Secret Chats/通话）	✅ Signal Protocol 全默认	✅ Signal Protocol 全默认
多设备/云同步	✅ 原生（云聊天）	受限（需设备迁移/ PIN 备份）	依赖 Google/Apple 云备份（可解密）
协议	自研 MTProto 2.0	开源 Signal Protocol（被广泛审计）	Signal Protocol
服务端	闭源	开源（AGPL）	闭源
大群/频道	20 万超级群 / 无限频道	群上限 ~1000	群上限 ~1024，频道（Channels）单向
大文件	2–4 GB	~100 MB	~2 GB
Bot/开放生态	✅ 庞大（Bot API、Mini Apps、TDLib）	❌ 几乎无	有限（Business API）
联邦化	❌ 中心化	❌ 中心化	❌ 中心化

10.2 Telegram 架构的优势

速度与弱网体验：MTProto 为"弱移动网络 + 大文件"定制：多连接会话、紧凑二进制 TL、传输混淆、可选 UDP 设计（✅ 官方 techfaq）。
云同步范式：换机即得全部历史，对大众用户是决定性体验优势。
开放客户端生态：TDLib + Bot API + Mini Apps 构成平台，Bot API 服务器甚至可自建。
反审查工程：obfuscated2/fake-TLS/MTProxy/MTProto-over-HTTPS（WEB 代理）是一整套 DPI 对抗工具链，在俄、伊朗等地经受实战检验。

10.3 已知短板

服务端闭源：云聊天的"服务器不可读"承诺不可验证；元数据（IP、在线状态、社交图谱）必然对服务器可见（📄 学界共识；Telegram 隐私政策承认收集 IP/设备信息最长 12 个月——📊 二手引用）。
自研密码学：MTProto 未经过 Signal Protocol 级别的长期公开审计；IEEE S&P 2022 论文证实了实际部署版本中的重排序攻击、客户端计时侧信道与密钥交换 MitM（📄）。
默认非 E2E：绝大多数用户对话对服务器可见，“安全通讯软件"的公众印象与技术现实存在落差（📄/📊 学界与媒体的持续批评）。
单点信任：RSA 公钥内嵌（TOFU）、DC 密钥由 Telegram 掌控，不存在 Signal 的 sealed sender / WhatsApp 的密钥透明度等机制。

10.4 公开故障反映的架构特点

2018-03-29 欧洲宕机：Durov 归因于数据中心供应商的计划维护事故，强调"美洲与东亚未受影响”——印证分区式多集群 + 地域故障隔离（📊 SiliconANGLE）。
2019-06 香港抗议期间：遭遇源自中国的国家级 DDoS，Telegram 将其公开归因——说明其边缘带宽与 DDoS 缓解是公开对抗的一部分（📊 Business Standard 引 Durov 推文）。
2022-02-24 俄乌战争：欧洲集群"前所未有的负载"致间歇故障——说明 DC 分区在流量洪峰下仍是瓶颈点（📊 massnews）。
2026-09-08 DC5 故障：亚太区中断而其他 DC 正常——印证账号-DC 强绑定既是扩展手段也是故障域边界；“DC5 又挂了"已成中文社区熟知现象（📊 cryptobriefing/smebuddies；💬 社区讨论）。

11. 核心结论摘要

Telegram 是有意为之的中心化云架构：自研 MTProto + 自营 5 DC + 闭源服务端，用"默认云同步"换"默认 E2E”，这是产品哲学的顶层取舍，而非技术债（✅ 官方 FAQ/techfaq）。
MTProto 2.0 是一个"大致安全但非标准"的记录协议：SHA-256/msg_key 含 padding/方向分离密钥派生修复了 1.0 的 CCA 问题；但 IEEE S&P 2022 Distinguished Paper 证实实际部署版仍存在重排序攻击、客户端计时侧信道与密钥交换 MitM（✅+📄）。
密钥体系分三层：长期 auth_key（2048-bit DH，每 DC 一个，几乎不变）+ 每日轮换的临时 auth key（云聊天 PFS）+ 秘密聊天/通话的 per-chat DH 密钥（100 条消息或 1 周重协商）（✅ 官方文档；📄 eprint 2025/451）。
传输层是反审查工程的一部分：abridged/intermediate/full 封装 + AES-128-CTR 混淆（无密码学意义）+ obfuscated2（dd 随机填充 / ee fake-TLS 仿冒 Chrome）+ MTProxy 中继——专为对抗 DPI 与封锁设计（✅+📊）。
同步模型是游标式差量：pts（消息盒）/ qts（秘密聊天）/ seq（通用）+ 频道独立 pts，getDifference 补缺口；账号强绑定 home DC，*_MIGRATE_X 是分片路由机制（✅ 官方 api/updates）。
媒体架构分两层：Telegram 服务器存原件 + 第三方加密 CDN（AES-256-CTR、每文件独立密钥）只缓存 10 万+ 成员公开频道媒体；私密数据不上 CDN（✅ 官方 techfaq）。
群组/频道靠"读时扩散"扩展：频道消息存一份、订阅者按频道 pts 拉取；超级群 20 万成员上限、频道订阅无限；已读/浏览为聚合计数器（✅ 官方；fan-out 内部实现为 💬 推测）。
Bot 生态是"HTTPS 中继 + TDLib 后端"：Bot 不碰 MTProto；Bot API 服务器官方开源可自建（--local 解锁 2GB 上传/不限下载）；Mini Apps 以 initData + HMAC-SHA256(bot_token,“WebAppData”) 为信任根（✅ 官方）。
通话是 Telegram 中 E2E 最彻底的部分：一对一通话 DH 三消息承诺 + AES-CTR 媒体 + P2P/WebRTC 优先、中继只转密文；2025 年起群组会议也 E2E 化（“blockchain-like” 防秘密加入，细节未全公开）（✅ 官方）。
最大短板不在密码学而在信任模型：服务端闭源 + 默认云聊天可读，隐私保证依赖"跨法域分布式 + 零披露承诺"而非数学不可读；TON 事件证明 Telegram 会在监管压力下切割业务线，但消息架构本身从未与链耦合（✅+📄+📊）。

Sources

官方文档（core.telegram.org，2026-10-06 live 读取）

MTProto 协议总览：https://core.telegram.org/mtproto（verified live）
客户端安全指南：https://core.telegram.org/mtproto/security_guidelines（verified live）
技术 FAQ（含 IND-CCA、IGE、加密 CDN、通话认证）：https://core.telegram.org/techfaq（verified live）
授权密钥生成：https://core.telegram.org/mtproto/auth_key（index，经官方文档内链与多方引用确认）
秘密聊天 E2E：https://core.telegram.org/api/end-to-end（verified live）
语音/视频通话 E2E：https://core.telegram.org/api/end-to-end/video-calls（verified live）
群组通话 API：https://core.telegram.org/api/group-calls（verified live）
更新/同步机制：https://core.telegram.org/api/updates（index）
云聊天 PFS（临时授权密钥）：https://core.telegram.org/api/pfs（index，经官方方法文档引用确认）
Mini Apps：https://core.telegram.org/bots/webapps（index）

官方其他

telegram.org/press（2026-10-06 live）：10 亿 MAU、迪拜总部
telegram.org/faq（经 archive.org 摘录读取）：为何不默认 E2E、多法域分布式、20 万超级群/无限频道、浏览计数器
telegram.org/blog/group-calls-made-easy（index，2025-04）：E2E 群组通话
GitHub github.com/tdlib/td（2026-10-06 live）：TDLib 设计、43k bots/实例
GitHub github.com/tdlib/telegram-bot-api（index）：自建 Bot API、--local 模式
GitHub github.com/TelegramMessenger/MTProxy（index，经社区引用确认）：官方 MTProxy

学术论文

📄 Albrecht, Mareková, Paterson, Stepanovs, “Four Attacks and a Proof for Telegram”, IEEE S&P 2022（Distinguished Paper Award；ieee-security.org/TC/SP2022/awards.html；全文 mtpsym.github.io）
📄 Miculan & Vitacolonna, “Automated Symbolic Verification of Telegram’s MTProto 2.0”, arXiv:2012.03141 (2020)（ProVerif 符号验证）
📄 Jakobsen & Orlandi, “On the CCA (in)security of MTProto”, IACR ePrint 2015/1177（MTProto 1.0 CCA 攻击根源）
📄 “Analysis of the Telegram Key Exchange”, IACR ePrint 2025/451（密钥交换形式化分析、临时 auth key 每日轮换）
📄 TGDataset, “Collecting and Exploring the Largest Telegram Channels Dataset”, arXiv:2303.05345（20 万群/无限频道/2GB 文件的学界复述）

新闻与社区（📊/💬）

TON 时间线：CoinDesk（2020-05-25 撤诉、2020-06-25 和解）、SiliconANGLE（2020-05-25）
DC 位置：Pyrofork 社区文档、GIGAZINE 2026-08-15
故障：SiliconANGLE 2018-03-29、9to5Mac 2018-03-29、Business Standard 2019-06-13（DDoS）、massnews 2022-02-24、cryptobriefing/smebuddies 2026-09（DC5）
规模：TechCrunch 2015-09-21（120 亿消息/日）
2026-07 Gram 钱包：crypto.news、Cointelegraph、TechBullion
混淆/fake-TLS：Hacker News 讨论（2018）、wzgram 对 TDLib TlsInit.cpp 的分析
同步机制社区实现参考：monogram AGENTS.md、tgbotstoolkit 文档镜像

未能验证 / 开放问题

服务端语言与技术栈：官方零披露，本报告未做断言。
各 DC 的确切物理位置与容量：仅社区测定，无官方确认。
频道 fan-out 与超级群写扩散的服务端内部实现：官方未公开，报告中为推测。
DAU/日消息量/峰值并发的最新官方数字：官方仅确认 10 亿 MAU（2025）；其余为二手数据。
E2E 群组通话"blockchain-like"安全的具体密码构造：官方未完全公开。

1. 整体架构与设计哲学#

1.1 中心化架构：有意为之的非联邦设计#

1.2 多数据中心与账号分片#

1.3 为何不做默认端到端加密#

2. MTProto 协议#

2.1 协议分层#

2.2 MTProto 2.0 相对 1.0 的改进#

2.3 授权密钥生成（Authorization Key）#

2.4 加密原语：AES-IGE / AES-CTR 的使用#

2.5 消息序号、会话与盐#

2.6 混淆传输与 MTProxy#

3. 服务端基础设施#

3.1 技术栈：公开信息极少#

3.2 数据中心与媒体 CDN#

3.3 大文件存储与分片下载#

3.4 消息队列与推送#

3.5 规模数字#

4. 数据模型与同步#

4.1 云聊天 vs 秘密聊天的存储差异#

4.2 多设备同步：updates / pts / qts / seq#

4.3 已读回执与在线状态#

5. 客户端架构#

5.1 各端开源情况#

5.2 TDLib 的设计#

5.3 第三方客户端生态#

6. 群组与频道架构#

6.1 类型与规模#

6.2 fan-out 实现思路#

6.3 置顶 / 慢速模式等机制#

7. Bot 生态架构#

7.1 中继式架构#

7.2 长轮询 vs Webhook#

7.3 可自建 Bot API 服务器#

7.4 Mini Apps / WebApp 架构#

8. 音视频通话#

8.1 一对一通话：E2E 与密钥协商#

8.2 P2P 与中继的选择#

8.3 群组通话的中继架构#

9. 区块链相关：TON#

9.1 TON（Gram）项目始末#

9.2 对 Telegram 架构的影响#

9.3 独立发展现状（简述）#

10. 工程取舍与对比#

10.1 与 Signal / WhatsApp 的关键架构差异#

10.2 Telegram 架构的优势#

10.3 已知短板#

10.4 公开故障反映的架构特点#

11. 核心结论摘要#

Sources#

官方文档（core.telegram.org，2026-10-06 live 读取）#

官方其他#

学术论文#

新闻与社区（📊/💬）#

未能验证 / 开放问题#