messages表
保存的消息记录(Saved Messages)

bff,session
TON以及tdlib
官方版设置中文 tg://setlanguage?lang=classic-zh-cn
https://web.telegram.org/k/
https://web.telegram.org/a/

https://github.com/TGX-Android
https://github.com/NekoX-Dev/NekoX, 内置公共代理不可用
nebula.chat:企业版客户端。

activitypub:开放社交网络的分布式网络协议

mtproto的go实现

teamgram的linux服务端 Docker部署
CentOS7 teamgram-server环境搭建
signal号称所有数据在用户手上，服务端只存储了无法解密的加密数据，tg里只有secretchats与之功能一样，其他的所有数据tg的服务端理论上可以看
因为tg的服务端存储的不是加密数据，所以才能推出超大群/订阅号等功能，但signal应该是无法支持较大群的
即使是基于signal协议或tg的secretchats机制，但如果开发商留个后门，偷偷上传客户端key，这种情况服务端也能够查看加密数据。

加密有两种，一种是像signal那样，数据即使服务端也无法解密，这只能基于signal协议或tg的secretchat机制。
另一种是服务端对数据的加密，这仅仅是减少因为黑客攻击或其他的导致数据泄露的风险，但理论上服务端（运营方）是有办法查看你的聊天数据的

https://telegram.org/blog/passport 授权其它应用登录

社区版只支持普通聊天和200人以下小群，短信验证码要自己接入.开源版不支持web.
只能搜到设置了username的用户，搜到了才能加好友。没有channel功能
开源的能私聊和群聊.其他功能都需要授权.语音通话不支持
rtc/bots等收费

dc的ip:154.175.55.149。tg handshake 之后会把dc地址保存到安卓本地tgnet.data文件。可以调试代码
主机的话最低配 4核8G

https://github.com/nebula-im/imengine teamgram最早验证版本

tg仅在端到端加密里才有阅后即焚

用户组权限由创建者或管理员在app里控制。底层的权限控制逻辑代码有

c++:folly 是 fb的c++基础库，相当于google的base库，是所有fb的开源c++项目的最底层的库.
基于folly的wangle，相当于fb的c++版本的netty
proxygen是基于wangle的http系列库，支持HTTP/1.1, SPDY/3, SPDY/3.1, HTTP/2, and HTTP/3等
用好这些，单机百万级连接，高性能服务端支持都能仰望了

message id是一个单调连续递增的id，teamgram用的是redis生成的，你可以用其他方式生成，比如zookeeper或etcd等
tg的消息（私聊和群消息）是基于user的单调连续递增id
getNextId，这是服务端做的

TG在创建auth key的时候，服务器第一次会返回一个小于等于2^63-1的pq，它是两个素数的乘积
client 与 server 通信是需要 auth_key 生成 aes_key 来加密的.每个设备都要同步消息

发消息：大群和channel读扩散，小群和普通聊天写扩散
tg的mid有两种：
一种是基于用户的，也就是所谓的写扩散消息，单调连续递增
另一种是基于大群和订阅号的，也就是所谓的读扩散，单调连续递增

但从客户端代码看，仅仅需要单调递增，不是连续也没什么关系

uidgen/seqsvr: 序列号生成器:微信的seqsvr最大的问题是一个集群只支持一个序号,一个集群最少3台机器保证一套seq
量不大也可以直接用mysql,redis,大场景上阿里云的话，一劳永逸的方案是用tablestore

pts包含了所有需要同步的事件

1.数据库里面能看到消息，但是没有推送过来

查一下日志，一般两种情况：

1. kafka是否正常工作
2. redis数据是否丢失，注意序号服务(idgen)的redis的数据要持久化

2.redis aof file 丢失

目前的解决方案是通过修复工具手动修复
完全丢失可以从db里捞

3.群消息

1.消息列表

消息体3523227325 这个是群ID 后面是消息递增ID

这里再记录一条 这个群ID 的最新消息递增ID
当用户 打开会话列表时 他只会去读取 MESSAGE_CACHE:3523227325_18。
当用户进入会话ID聊天界面后 再去读取 MESSAGE_CACHE:3523227325_*

2. 会话列表管理

会话列表单独存储，存在APP本地库，只需要存储 会话ID

新消息 让用户去监听读取，用户只需要知道 会话ID的最新消息ID ，用户本地去读取获得。循环去读会话ID
当会话ID 服务器最新消息值 和本地值有差异， 就增加未读数， 获取最新内容 渲染到消息列表
会话ID GROUP_3846113625 本地 SEQ 等于18 服务器SEQ ID 等于18 不变

会话ID GROUP_3846113625 本地 SEQ 等于18 服务器SEQ ID 等于20 未读消息+2 拉取 seq 20 消息内容

4.问题

1. updating 发送成功 接收不到

1. 检查kafka是否正确工作
2. 检查redis是否运行正常
3. 查一下错误日志 logs/bff/error.log， logs/msg/error.log

2.错误

ERR_ENTERPRISE_IS_BLOCKED 表示开源版不支持的功能
INTERNEL_SERVER_ERROR 是服务端问题，表明安装配置有问题

5.api

https://core.telegram.org/methods
updates.getState 获取服务端状态，一般第一次登录时会调用
messages.readHistory(peer: InputPeer.inputPeerUser(userId: 100002, accessHash: 6761312346070604377), maxId: 10605)

客户端重连一定要优先走getDifference 流程 ,不然各种掉消息 不同步问题
secret chat在初始化的时候，假如消息的接收方不在线,暂存消息,等对方上线了 再完成密钥交换.
updateEncryption#b4a2e88d chat:EncryptedChat date:int = Update;这个类型没有qts，看起来Telegram官方在实现的时候只是把初始化会话相关的消息暂存了一
离线再上线 先走getDifference 里面的otherupdates字段放进去就行了 然后请求和返回的state里面有qts 用来做偏移查询
客户端一定要先处理other_updates，然后再处理new_messages和new_encrypted_messages

6.Telegram 客户端与服务端的交互流程：

Telegram 客户端发送请求到服务器：Telegram 客户端通过与服务器建立的 SSL/TLS 安全连接向服务器发送请求。Telegram 使用自己的协议（MTProto）进行通信，而不是 HTTP 协议。

Telegram 服务器进行身份验证并返回响应：Telegram 服务器通过验证请求中包含的用户身份信息，并在必要时要求客户端进行身份验证。一旦身份验证完成，服务器会生成响应并通过 SSL/TLS 安全连接发送回客户端。

Telegram 客户端解密和处理响应：Telegram 客户端使用服务器提供的密钥对响应进行解密和验证，并通过客户端的动态方法调用（动态方法调用是 Telegram 协议的一个重要特性，它允许客户端和服务器自由地交换数据）将响应中的数据传递到客户端应用程序中。

Telegram 客户端处理响应并进行后续操作：Telegram 客户端接收到服务器响应后，会根据响应的类型执行相应的操作，例如更新用户的聊天列表、发送聊天消息、下载文件等等。这些操作通常涉及到与服务器的多次通信，以确保数据的顺序性和一致性。

总体来说，Telegram 的客户端与服务器的交互是通过安全的 SSL/TLS 连接进行的，整个流程非常灵活和高效，使得 Telegram 能够提供高质量、高速度及可靠性的服务。

Api的 CrC32 的生成，就是截图的TLconstructorSignature 的内容

7.压力负载测试

基于tdlib( https://github.com/teamgram/teamgram-td )或madeline( https://github.com/teamgram/teamgram-madeline )定制一个压测客户端

8.加密

1. secretchat是密文，服务端也无法解密
2. 其他的数据目前是明文存储，如果有需求，能加密存储，但是运维时一定要保护好数据加密key

9.Layer

Telegram的Layer是一种通信协议，它由多个层组成。每个层都有不同的功能，用于处理不同的任务和数据传输。

以下是Telegram的Layer各层的功能：

Layer 1：处理基本的数据传输和加密。
Layer 2：添加了消息确认和重试机制。
Layer 3：添加了消息序列化和压缩功能。
Layer 4：添加了分片传输和快速重传功能。
Layer 5：添加了支持代理服务器的功能。
Layer 6：添加了支持VoIP（Voice over Internet Protocol）和视频通话的功能。
Layer 7：添加了支持文件传输和更高级别的加密功能。
每个层都建立在前一个层的基础上，并添加了新的功能和改进。这些层一起构成了Telegram的通信协议，使得Telegram可以高效地传输数据并保护用户隐私。

Telegram的协议版本有很多，以下是一些较为重要的版本及其作用：

Layer 1：最初的Telegram协议版本，支持基本的消息传递和文件传输功能。
Layer 17：引入了加密聊天功能和群组聊天功能。
Layer 23：引入了语音通话和视频通话功能。
Layer 39：引入了公共频道和超级群组功能。
Layer 52：引入了内置支付功能。
Layer 86：引入了可编辑消息、快速回复和多项选择等新功能。
每个协议版本都有不同的功能和改进，旧版本的客户端将无法访问新版本的功能，因此需要升级。同时，新版本的协议可以提高安全性和性能。

10.MTProto

MTProto是Telegram使用的加密协议，用于保护用户数据的安全性和隐私。它是一种自主开发的加密协议，与其他加密协议（如TLS和SSL）不同。
MTProto使用称为“Diffie-Hellman密钥交换”(Diffie–Hellman key exchange)的算法来协商会话密钥，该算法允许客户端和服务器在不泄露密钥的情况下进行安全通信。

MTProto还使用称为“AES-256-CBC”（高级加密标准）的对称加密算法来加密通信。该算法是当前最安全的加密算法之一，它使用256位密钥来保护数据的机密性。

此外，MTProto还使用称为“Perfect Forward Secrecy”的技术来保护用户数据的安全性。这意味着即使攻击者能够获得以前的通信记录，也无法解密以后的通信记录。

总的来说，MTProto是一种非常安全和可靠的加密协议，它为Telegram用户提供了高水平的安全保障

tg 没有 .proto 文件
所有的 .proto 都是外面这些开发根据 tg协议生成的 大多都是参照 windows开源代码里的 schemel.tl文件生成的

11.技术实现

tdlib:用于构建Telegram客户端的跨平台库

协议最外层支持了Transport层相关的一些特性，比如精简版本，QuickACK；再往里面一层是MTProto层，确定了协议的版本之后，MTProto层主要是安全层面的考虑，
所有的安全相关的机制都在这一层处理，比如授权密钥（确保会话的安全性），消息的签名msg_key（确保消息未经篡改）；最后是加密过的payload，payload对应就是具体的应用层协议了。

支持PFS.
完美前向保密 (PFS : Perfect Forward Secrecy)，也称为前向保密，是一种允许客户端和服务器之间进行短期私钥交换的加密方式

最麻烦的是frontend、handshake和session这块

1. 对于10w的大群，tg群聊一条消息的延迟性为什么感觉不出来？

应用层多播，参考直播弹幕的实现
假如10W人都在线，如果有一百台网关，一个网关也就是1000个在线。网关机订阅统一的10W人群的下推通道，真正的消息扇出就分散到了网关机上，每个也就1000个在线客户端的下推

2.tg的未读消息计数

用msgid 来减
当前超级群最大msgid - 用户已读msgid -（再排掉这个范围内 被删除的消息数量）就是用户未读数
超级群是读扩散 共用一份历史数据 msgid 肯定是连续的啊

官方149.154.167.51 ，
47.103.102.219 社区版

12345
5222
电商、办公类的im都是永久保存的

https://www.betaqr.com/ fir.im 为开发者提供测试应用极速发布，应用崩溃实时分析、用户反馈收集等一系列开发测试效率工具服务
https://github.com/DanTheMan827/ios-app-signer, iOS重签名

https://sms-activate.org/ ，虚拟号码平台

12.IM相关

一套高可用实时消息系统实现:大规模用户

goim

Telegram 客戶端版本比較

1.同类项目：

openim，rocket.chat，铁丝，
wire，tox，matrix的element,
https://www.potato.im/
Signal,mattermost

Mastodon:p2p模式IM,但是可以污染个别实例的域名

Python实现的Telegram MTProto库

Telethon:Pure Python 3 MTProto API Telegram client library, for bots too!

im	e2e端对端加密	阅后即焚	UI
signal	Y	Y	好
Tinode	N	N	简洁
Tox	Y	N	X
Briar	支持tor	N	X
Matrix	Y	N
Jabber	N	N
NebulaChat	Y	Y

fragment.com
c#服务端im：https://github1s.com/loyldg/mytelegram

IRC：应用层的协议。其主要用于群体聊天，但同样也可以用于个人对个人的聊天。早期
STUN：P2P网络要求通信双方都能主动发起访问，但是NAT设备的存在，却阻断了这种主动访问，导致P2P应用无法正常运行。STUN是一种解决P2P应用NAT穿越问题的常用技术。
它允许网络设备找出通信端点经NAT设备后的IP地址和端口号，并利用这些信息在通信双方之间建立一条可以穿越NAT设备的数据通道，实现P2P通信

使用MTProto协议:pyrogram
客服机器人
Telegram（电报）：新手指南、使用教程及频道推荐