以下是来自与电报服务器进行简单TCP握手的示例数据:

here is sample data from a simple TCP handshake with Telegram Servers:

Connect:Success:0
Connected to 149.154.167.40:443

    raw_data: 000000000000000000F011DB3B2AA9561400000078974660A9729A4F5B51F18F7943F9C0D61B1315
 auth_key_id: 0000000000000000  0
  message_id: 56A92A3BDB11F000  6244568794892726272
 data_length: 00000014  20
message_data: 78974660A9729A4F5B51F18F7943F9C0D61B1315
message_type: 60469778

>> EF0A000000000000000000F011DB3B2AA9561400000078974660A9729A4F5B51F18F7943F9C0D61B1315
Send:Success:42
Receive:Success:85
<< 15000000000000000001CC0CC93D2AA9564000000063241605A9729A4F5B51F18F7943F9C0D61B1315B4445B94718B3C6DD4136466FAC62DCD082311272BE9FF8F9700000015C4B51C01000000216BE86C022BB4C3

    raw_data: 000000000000000001CC0CC93D2AA9564000000063241605A9729A4F5B51F18F7943F9C0D61B1315B4445B94718B3C6DD4136466FAC62DCD082311272BE9FF8F9700000015C4B51C01000000216BE86C022BB4C3
 auth_key_id: 0000000000000000  0
  message_id: 56A92A3DC90CCC01  6244568803180334081
 data_length: 00000040  64
message_data: 63241605A9729A4F5B51F18F7943F9C0D61B1315B4445B94718B3C6DD4136466FAC62DCD082311272BE9FF8F9700000015C4B51C01000000216BE86C022BB4C3
message_type: 05162463


     classid: resPQ#05162463
       nonce: A9729A4F5B51F18F7943F9C0D61B1315
server_nonce: B4445B94718B3C6DD4136466FAC62DCD
          pq: 2311272BE9FF8F97  2526843935494475671
       count: 00000001  1
fingerprints: C3B42B026CE86B21  14101943622620965665

让我们分解一下:

1. 我们使用的是TCP简化版，因此我们从0xEF开始

1. We are using the TCP abridged version, so we start off with 0xEF

纯文本电报消息的格式为auth_ke_id + msg_id + msg_len + msg

The format for plain-text Telegram messages is auth_ke_id + msg_id + msg_len + msg

auth_key_id始终为0，因此我们始终以0000000000000000

auth_key_id is always 0 for plain-text messages hence we always start with 0000000000000000

msg_id必须近似等于unixtime*2^32(请参阅在这里)，我还发现，该版本的某些变体对于msg_id在任何平台上的任何语言下都非常有效:whole_part_of(current_micro_second_time_stamp * 4294.967296)

msg_id must approximately equal unixtime*2^32(see here) I have also seen that some variant of this works quite well for msg_id in any language on any platform: whole_part_of(current_micro_second_time_stamp * 4294.967296)

用于生成Auth_key的第一条消息是reqPQ，其定义为:reqPQ#0x60469778 {:nonce, :int128}，因此它只是一个TL标头+ 128位随机整数，总长度始终为4 + 16 = 20编码为小尾数，即msg_len = 14000000

The first message you start with for Auth_key generation is reqPQ which is defined as: reqPQ#0x60469778 {:nonce, :int128} so it is simply a TL-header + a 128-bit random integer the total length will always be 4 + 16 = 20 encoded as little-endian that would be msg_len = 14000000

假设我们有一个128位随机整数= 55555555555555555555555555555555555，那么我们的reqPQ消息将是7897466055555555555555555555555555555555555555，这是TL型60469778或little-endian中的78974660，然后随机选择128位随机数.

say we have a 128-bit random integer= 55555555555555555555555555555555, then our reqPQ message would be 7897466055555555555555555555555555555555, which is simply TL-type 60469778 or 78974660 in little-endian followed by your randomly chooses 128-bit nonce.

在发送数据包之前，再次回想一下，TCP简化模式要求您将总数据包长度包括在初始0xEA之后的其他字节之前.该数据包长度计算如下

Before you send out the packet, again recall that TCP-abridged mode required you to include the total packet length in front of the other bytes just after the initial 0xEA . This packet length is computed as follows

let len = total_length/4

let len = total_length / 4

a)如果len < 127然后len_header = len as byte

b)如果len >=127，则len_header = 0x7f + to_3_byte_little_endian(len)

最后我们有:

EF0A000000000000000000F011DB3B2AA956140000007897466055555555555555555555555555555555

或

EF0A
0000000000000000
00F011DB3B2AA956
14000000
78974660
55555555555555555555555555555555

与您的相比:

0000000000000000
6C28224A94A9C956
14000000
78974660
68EDEAECD1372139BBB0394B6FD775D3

我想说的是，尝试使用TCP简化模式，方法是包含0xEF起始位，然后重新检查您的msg_id计算

I would say, try using TCP-abriged mode by include the 0xEF starting bit and re-check your msg_id computation

欢呼.