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.数据库里面能看到消息,但是没有推送过来
查一下日志,一般两种情况:
- kafka是否正常工作
- 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 发送成功 接收不到
- 检查kafka是否正确工作
- 检查redis是否运行正常
- 查一下错误日志 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.加密
- secretchat是密文,服务端也无法解密
- 其他的数据目前是明文存储,如果有需求,能加密存储,但是运维时一定要保护好数据加密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(电报):新手指南、使用教程及频道推荐