QQ传输协议分析
http://www.mamicode.com/info-detail-866314.html一、 实验目的：
在虚拟机下NAT模式下通过Wireshark抓包，分析QQ的传输模式。了解QQ在传输信息过程中用到的协
议。分析在Nat模式下，信息传输的穿透性。
二、 实验环境：
Win7 专业版32位（在虚拟机里面）。
Win7 旗舰版64位（物理机）
QQ版本：TM2013
Wireshark
三、 实验内容：
1、 QQ登录
1)、UDP登录
在虚拟机的win7打开QQ面板，设置登录服务器的类型为UDP
启动wireshark，然后开始登录QQ，登录成功等待一会儿停止wireshark的抓包。
抓包如图：
我们可以看到本地向远程登录服务器183.60.48.174发送了一个UDP的数据包，这个就是IP就是在刚
才设置UDP登录时的系统默认IP，还可以看到这个IP返回了一个UDP的数据包。看来这两个包就应该是登
录验证的包，接下来的几个包的服务器IP变成了183.60.48.165，由于这个IP和登录服务器的IP位于统一
网段，因此我们可以猜测这个IP是腾讯用来存储我们发送的信息的服务器。需要注意的是，在多次实验
下，可以发现服务器不止183.60.48.165这一个，这是因为想QQ这样的大吞吐量的信息交互，必须用多台
服务器分流，所以这个IP并不一定是某一个。下面的一些包应该就是心跳包。那个OIQC协议就是QQ用的
协议，其实实际上也是一个UDP包。下面的DNS协议就是因为我的QQ是在虚拟机里面登录的，在向外网交
互信息的时候会通过网关192.168.214.2解析。
我们来分析一下登录时候的UDP包
从这个图我们可以得知源和目的的IP，mac地址，还有双方的端口号等等一些信息。
数据链路层：
目的MAC地址：00 50 56 e3 56 95
本机MAC地址: 00 0c 29 ba 59 3c
网络层：
通过查询资料和分析我们知道：
45：版本IPv4，首部长度20字节
00：区分服务
00-73：总长度175字节
36-1e：标识
00-00：标志和偏移
80：生存时间128
11：传输协议UDP(17)
传输层：
0f-a0：源端口4000
1f-40：目的端口8000
009b：长度155字节
7f-c4：检验和
QQ的数据
通过查询资料和分析我们知道：
02：QQ报文的开头
34-20：QQ客户端的版本号，实验所用版本为QQTM2013
08-25：用户请求登陆的命令的序号
67-dc：发送数据的序号
56-a6-d2-5c：用户QQ号码，实验中为1453773404
之后的内容为加密的数据内容
最后一个字节03：QQ报文的结尾
2)、TCP登录
设置如图：
启动wireshark，然后开始登录QQ，登录成功等待一会儿停止wireshark的抓包。
抓包如图：
可以看到几个TCP的包还有一个SSL的包
对TCP包分析如图：
通过对UDP协议的分析，我们可以看到数据层和网络层的十六进制代码和之前的一模一样，这里我们
就值分析传输层的TCP协议了，如图：
通过查询资料和分析我们知道：
C4-5e：源端口号50270
01- bb：目的端口443
45-34-fc-63：序号
00-00-00-00：确认号
80-02：数据偏移，标志
20-00：窗口大小8192字节
7f-3b：检验和
00-00：紧急指针
其余部分为可选字段和填充字节
在TCP协议里面我们没有看到QQ的登录验证消息。为什么呢？一看这里还有一个SSL协议，QQ会不会
是通过SSL验证的呢？
SSL（(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，
TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。）
那么我们来看看这个包：
02：QQ报文的开头
34-20：QQ客户端的版本号，实验所用版本为QQTM2013
08-25：用户请求登陆的命令的序号
67-dc：发送数据的序号
56-a6-d2-5c：用户QQ号码，实验中为1453773404
之后的内容为加密的数据内容
最后一个字节03：QQ报文的结尾
可见，这个包的信息和UDP登录时候的一样，那么TCP登录是确实使用了SSL。
2、 心跳消息数据包
如图，通过IP地址查询，可以知道119.147.45.40是广东深圳的IP，而深圳是腾讯的老巢。在多次的
抓包中也可以看到这个IP段，所以我们有理由相信，这个IP段是腾讯的。
那么我们打开来看看。
看到这里，确实有很熟悉哦。通过查阅资料和分析我们知道：
通过查询资料和分析我们知道：
02：QQ报文的开头
34-20：QQ客户端的版本号，实验所用版本为QQTM2013
00-58：用户在线的命令序号
3b-09：发送数据的序号
56-a6-d2-5c：用户QQ号码，实验中为1453773404
之后的内容为加密的数据内容
最后一个字节03：QQ报文的结尾
3、 收发信息数据包
对方在线的时候
我们看看第一个包：
可以看到蓝色字体那里的02是QQ报文的开头，这里需要注意的就是00-cd是客户端向服务器发送消息
的命令序号，1b-db是发送数据序号，其他的都一样。通过几次实验发现，00-cd客户端向服务器发送消
息的命令序号是固定的，而1b-db发送数据序号是会改变的。
而且没每送一个包，服务器是会回复一个包给客户端的。
四、实验总结：
通过实验我还发现QQ貌似是会和每一个在线好友建立一个连接，因为当我登录只有一个好友的QQ时
，wireshark抓到的包就几个，而登录有上百好友的QQ时，发现连接数也有数百个。
PS：这是去年10月份我们老师给我们讲网络协议时，自己做的一次对QQ协议的分析，当时自己对于协议
也不是很明白，但是通过查阅资料，还是独立完成了这么一次分析，由于时间过得太久，当时查阅的资
料早已忘记出处。真的很感谢网络上前辈们、朋友们的无私分享，我们今天才得以有那么多资料查阅，
衷心感谢！还要感谢姚老师的指导。文中有错之处，还望批评指出，在此先谢过！
========
一份旧QQ协议体系概述
http://www.qqxieyi.com/fenxi_show.asp?id=40QQ协议体系概述
1. QQ协议体系概述
2. 请求登录令牌
3. 登录
4. 改变状态
5. 得到好友列表
6. 得到在线好友
7. Keep Alive
8. 得到用户资料
9. 登出
10. 查找用户
《狂迷 2005-10-28 14:22:26》
QQ的协议非常庞大，这些做一些概述，要注意，不要认为下面的说法一定是对的，只能说目前看起来好
像是这样:
加密解密
QQ的加密解密用的是TEA算法(puzzlebird的说法)，不详细解释了。QQ的包一般都是加密的（包头包尾除
外），但是有个别包是不加密的，以后 如果不做特别说明，则默认这个包是需要加密的。此外，用什么
密钥加密也有不同，不过基本上都是用会话密钥加密，以后如果不做特殊说明，表示是用会话密钥加 密
。这里要注意一下，有时候你收到的包可能不是用会话密钥加密的，比如离线的消息。你人都不在了，
哪里来的会话密钥？所以服务器在你下次登录的时候，会把 你还没收到过的消息用密码密钥加密再传给
你。这是一种特殊的情况，要分清楚。
UDP和TCP
QQ支持UDP和TCP登录（如果使用HTTP代理，则相当于TCP登录），UDP登录没有什么好说的，TCP登录时，
不管什么包的开头两字节都是包长度，这个长度包括了这两个字节。
包头包尾
QQ协议有多种包头，每种包头都分别代表了一类用途的包，但是不是所有的包都有包尾，以下是一些存
在的包头包尾格式参考
包头 包尾 包头之后的固定格式 说明
0x00 无 发送方QQ版本，或者是服务器版本，2字节
随机密钥，1字节，如果这个字节是0x23，那么密钥就是0x23232323，这个密钥用来加密发送者和接受者
的QQ号。加密算法: QQ号取反再与密钥异或
发送者QQ号的加密形式，4字节
接受者QQ号的加密形式，4字节
0x00系列的包，用在文件传输过程中，传递控制信息。也会出现在点对点通信中。
0x02 0x03 源标志, 2字节，表示了这个包从何处来，主要用来标识客户端版本，如果其标识的是服务器
，这个字段的具体用处还不清楚
包命令, 2字节
包序号, 2字节, 原则是保证短期内这个序号不要重复就可以，一般我们处理的时候都是递增，到最大再
归0
0x02系列包主要完成一些基本任务，基本上处理了这个系列的包，QQ的功能就差不多了。
0x03 无 格式同第一行 0x03系列的包，用在文件传输过程中，传递数据信息
0x04 0x03 客户端版本号，2字节
整个的包长，2字节
序号，2字节
我的QQ号，4字节
未知的8字节
0x04系列的包，用在文件传输过程中，如果使用服务器中转模式传送文件，则用到这些包
0x06 未知 未知 还没怎么研究过这种包是干什么的
狂迷 2005-10-28 14:23:43
请求登录令牌
登录QQ，要发的第一个包就是Request Login Token Packet。这个包会向服务器请求一个24字节大小的
令牌（也不一定是24，只能说目前是24字节），然后在接下来的登录中，没有这个令牌，你是登录不 了
的。这个令牌是在服务器端生成的，具体的生成算法我们当然还无从得知，但是它肯定是参考了你的IP
，你的端口，还有你的其他什么信息生成这个令牌的。因 为你把在A机器上得到的令牌用到B机器上，你
就会登录不了，如果你把A机器上的IP给改了，你照样也登录不了。
请求包格式
头部
未知的1字节，0x00
尾部
Note: 此包不加密
回复包格式
头部
回复码，1字节，0x00表示成功
登录令牌长度，1字节
登录令牌
尾部
Note: 此包不加密
成功时
操作成功时，核心层会触发QQ_GET_LOGIN_TOKEN_SUCCESS事件，这个事件携带的包是
RequestLoginTokenReplyPacket，可用的字段如下:
replyCode: byte，回复码
loginToken: byte[]，包含了得到的登录令牌
失败时
操作失败时，核心层会触发QQ_GET_LOGIN_TOKEN_FAIL事件，这个事件携带的包是
RequestLoginTokenReplyPacket，可用的字段如下:
replyCode: byte，回复码
狂迷 2005-10-28 14:24:14
登录
QQ登录目前有多种模式，比如普通QQ号，电子邮件登录，绑定手机号登录，还有什么普通模式，TM模式
。目前我们只支持普通模式和QQ号登录。
请求包格式
头部
初始密钥，16字节
用户的密码密钥加密一个空串得到的16字节
36字节的固定内容，未知含义
登录状态，隐身登录还是什么，1字节
16字节固定内容，未知含义
登录令牌长度，1字节
登录令牌
登录模式，1字节，目前只支持普通模式
未知1字节，0x40
后面段的个数，1字节，1个段9字节(猜测)
段，每次基本都是固定内容，未知含义
长度不足则全部填0直到符合登录包长度，UDP模式登录请求包长度为416字节
尾部
Note: 此包使用初始密钥加密，注意头部之后就是初始密钥，初始密钥是不加密的。
说明
初始密钥在2004以前用的是一个固定值: 16个0x01字节。2004之后，采用随机密钥
密码密钥是通过对用户的密码进行2次MD5生成的
密码密钥加密一个空串是干什么呢？主要是服务器用来验证密码的，如果服务器能用密码密钥解开这16
个字节，那么它就认为密码是正确的。在这里，我们不一定非要加密一个空串，其实任意字符串都可以
，但是你要保证密文只有16个字节。
登录请求包的固定内容，含义是未知的，而且，也不能说内容是固定的，即使我们把这些字段全部替换
成0，依然能够登录
回复包格式
回复包可能有多种情况，包体的第一个字节是回复码，可能的取值如下：
QQ_LOGIN_REPLY_OK: 登录成功
QQ_LOGIN_REPLY_REDIRECT: 重定向
QQ_LOGIN_REPLY_PASSWORD_ERROR: 密码错误
QQ_LOGIN_REPLY_OK：
头部
回复码，1字节
会话密钥，16字节
用户的QQ号，4字节
用户的IP，4字节
用户的端口，2字节
服务器的IP，4字节
服务器的端口，2字节
本次登录时间，4字节
未知的26字节
未知服务器1的IP，服务器的作用未知，4字节
未知服务器1的端口，2字节
未知服务器2的IP，4字节
未知服务器2的端口，2字节
2个未知字节
2个未知字节
Client Key, 32字节
12个未知字节
上次登录时的IP，4字节
上次登录时的时间，4字节
8个未知字节
尾部
QQ_LOGIN_REPLY_REDIRECT：
头部
回复码，1字节
用户QQ号，4字节
重定向的服务器IP，4字节
重定向的服务器端口，2字节
尾部
QQ_LOGIN_REPLY_PASSWORD_ERROR:
头部
回复码，1字节
错误消息字符串
尾部
Note: 登录回复包使用密码密钥加密，或者使用初始密钥加密，在处理时，应该先尝试使用密码密钥解
密，如果失败，则再用初始密钥解密。为什么要这样呢，因为你可能密码输入错误，这样的话服务器用
密码密钥加密的包你就解密不了了，所以会用初始密钥加密。
说明
时间都是4个字节，其表示从1970-1-1开始的毫秒数再除以1000
Client Key是用在访问一些网络服务时，比如QQ秀，通过Client Key，TX可以直接定位到你的QQ秀页面
，还有什么QQ家园啦，有可能聊天室也要用到这个。
那些未知的服务器，可能是用来发广告用的，猜想～
成功时
登录成功或者重定向时，核心层会触发QQ_LOGIN_SUCCESS事件，这个事件携带的包是LoginReplyPacket
，用户应该检查replyCode的值，然后进行相应的操作：
当replyCode为QQ_LOGIN_REPLY_OK时，有以下字段可用：
sessionKey: byte[]，会话密钥
ip: byte[]，用户IP
port: int, 用户端口
serverIp: byte[], 服务器IP
serverPort: int, 服务器端口
loginTime: int, 本次登录时间
lastLoginTime: int, 上次登录时间
clientKey: byte[], Client Key
当replyCode为QQ_LOGIN_REPLY_REDIRECT时，有以下字段可用：
redirectIp: byte[], 重定向到的服务器IP
redirectPort: int, 重定向到的服务器端口
重定向到零地址时
在登录高峰期，登录重定向时有可能得到一个0地址，这时核心层会触发QQ_LOGIN_REDIRECT_NULL事件，
这个事件携带的包是LoginReplyPacket，不过这个包没有什么可用信息。
密码错误时
如果密码错误，核心层会触发QQ_LOGIN_PASSWORD_ERROR事件，这个事件携带的包是LoginReplyPacket，
可用的字段如下：
replyMessage: String, 错误信息字符串
未知错误时
如果回复码不是以上三种，则核心层会触发QQ_LOGIN_UNKNOWN_ERROR事件，这个事件携带的包是
LoginReplyPacket，但是没有可用字段。
狂迷 2005-10-28 14:24:47
改变状态
登录之后的第一件事就是切换自己的状态，不然你发不出消息，这个一定要注意了，不是登录成功之后
就能发消息，而是改变状态之后才能发消息。LumaQQ核心层自动处理登录后的状态改变，所以基本上你
可以不管状态改变的事件，就看你的需要了。
请求包格式
头部
想要切换到的状态，1字节，定义如下
QQ_FRIEND_STATUS_ONLINE: 在线
QQ_FRIEND_STATUS_OFFLINE: 离线
QQ_FRIEND_STATUS_AWAY: 离开
QQ_FRIEND_STATUS_HIDDEN: 隐身
是否显示虚拟摄像头，4字节，最低位置1表示显示虚拟摄像头，其他位似乎无用
尾部
回复包格式
头部
回复码，1字节，0x30表示成功，相关常量QQ_CHANGE_STATUS_REPLY_OK
尾部
成功时
操作成功时，核心层会触发QQ_CHANGE_STATUS_SUCCESS事件，这个事件携带的包是
ChangeStatusReplyPacket，可用的字段如下:
replyCode: byte，回复码
失败时
操作失败时，核心层会触发QQ_CHANGE_STATUS_FAIL事件，这个事件携带的包是
ChangeStatusReplyPacket，可用的字段如下:
replyCode: byte，回复码
狂迷 2005-10-28 14:25:42
得到好友列表
登录之后还需要得到好友列表。现在得到好友列表这个包重要性已经不太高了，因为这个包无法得到分
组信息，只能得到列表，你看到现在QQ 2004以上版本都是自动就把你的分组都同步下来，这个光用得到
好友列表的功能做不到，我想这个包现在只是做为兼容性的考虑还存在。
请求包格式
头部
起始好友列表返回位置，2字节。假设你有10个好友，这个字段你设置成3，那么就从第3个好友开始返回
，预期你应该得到7个好友。那么第三个是怎么界定 的？服务器是按照你的好友的QQ从小到大排序决定
的。另外，为什么需要这个字段，主要是怕你好友太多，一个包得不完，QQ服务器端的设定是一次只返
回50 个好友。
返回的好友列表是否排序, 1字节。相关常量如下：
QQ_FRIEND_LIST_SORTED: 排序
QQ_FRIEND_LIST_UNSORTED: 不排序
尾部
回复包格式
头部
下一次好友列表开始位置，2字节。你的好友很多，还需要再请求，那么你下次要把请求包中的起始位置
字段置成这个值。如果这个字段是0xFFFF，那就是服务器告诉你，你的好友都得到了。和起始位置相关
的常量有：
QQ_FRIEND_LIST_POSITION_START: 开始请求好友列表。你发第一个包的时候应该把起始位置置为这个值
QQ_FRIEND_LIST_POSITION_END: 好友已经全部得到
好友QQ号，4字节
头像，2字节
年龄，1字节
性别，1字节
昵称长度，1字节
昵称
2个未知字节
1字节扩展标志，bit1表示是否有QQ Show，其他未知
1字节通用标志
bit1 => 会员
bit4 => TCP方式登陆
bit5 => 开发移动QQ
bit6 => 绑定到手机
bit7 => 是否有摄像头
如果有更多好友，重复3 - 11部分
尾部
成功时
操作成功时，核心层会触发QQ_GET_FRIEND_LIST_SUCCESS事件，这个事件携带的包是
GetFriendListReplyPacket，可用的字段如下:
position: char, 下一个请求包的起始位置
friends: List, 包含了好友的信息，每个好友的信息由一个QQFriend类封装，请查看
edu.tsinghua.lumaqq.qq.beans.QQFriend.java文件了解这个类的字段信息
失败时
尚未有操作失败事件的定义，因为我不知道如何才是失败，这么久了，这个操作就从没失败过，所以我
不知道失败的包是什么样子的。
狂迷 2005-10-28 14:26:20
得到在线好友
一般在得到好友列表之后就是得到在线好友了，当然你也可以先得到在线好友再得到好友列表，这个没
什么限制。不过你可能会想：好友上线下线的时候会收到通 知，那还要得到在线好友干什么呢？因为这
种通知是不可靠的，可能由于种种原因，你经常会收不到这个通知，所以得到在线好友是必须的，QQ的
作法是在 Keep Alive的时候刷新一次来保持最新的在线列表，而Keep Alive是1分钟做一次的。需要说
明的是，这个请求包并非只能得到好友，注意看下面的包格式分析。
请求包格式
头部
好友类型，1字节。目前发现这个字节置为0x02或者0x03时服务器会有反应，其他都会返回0xFF。置为
0x02时，得到的就是好友，置为0x03 时，得到的是另外一些东西，b好像是系统服务，号码比如
72000001到72000013，就是那些移动QQ，会员服务之类的
在线好友列表起始位置，1字节，含义同得到好友列表中的起始位置字段，只不过它只根据在线的来排。
1个未知字节，一般设为0x00
2个未知字节，一般设为0x0000
尾部
回复包格式
头部
下一个请求包的起始位置，含义同得到好友列表的回复包。相关常量如下：
QQ_FRIEND_ONLINE_LIST_POSITION_START: 开始请求在线好友列表。你发第一个包的时候应该把起始位
置置为这个值
QQ_FRIEND_ONLINE_LIST_POSITION_END: 在线好友已经全部得到
好友的QQ号，4字节
未知的1字节
好友的IP，4字节。这里提一下，这个字段只有在点对点模式时才有值，如果对方设置的是服务器模式，
则这里都是0。但是在以前呢，都是有的，所以这是腾讯 服务器的一个bug，在腾讯发布2005 Beta1的这
段时间左右，它修正了这个bug，服务器模式不再返回ip了。所以珊瑚虫得到ip的效果已经打了折扣了。
不过对于这种这种情况，如来神掌依 然可以得到IP。
好友的端口，2字节
未知的1字节
好友的状态，1字节，相关常量如下，需要注意的是，隐身状态是得不到的，所以只会返回3种状态
QQ_FRIEND_STATUS_ONLINE: 在线
QQ_FRIEND_STATUS_OFFLINE: 离线
QQ_FRIEND_STATUS_AWAY: 离开
QQ_FRIEND_STATUS_HIDDEN: 隐身
未知的2字节
16字节的密钥，用处未知，不过猜想是用在点对点通信中
2个未知字节
1字节扩展标志，bit1表示是否有QQ Show，其他未知
1字节通用标志
bit1 => 会员
bit4 => TCP方式登陆
bit5 => 开发移动QQ
bit6 => 绑定到手机
bit7 => 是否有摄像头
2个未知字节
分隔符，1字节，0x00
如果有更多在线好友，重复3 - 15部分
尾部
说明:
回复包的3 - 15部分封装在edu.tsinghua.lumaqq.qq.beans.FriendOnlineEntry.java中，而3 - 10部分
又是封装在edu.tsinghua.lumaqq.qq.beans.FriendStatus.java中的，所以 FriendOnlineEntry里面包
含了一个FriendStatus的对象。
成功时
操作成功时，核心层会触发QQ_GET_FRIEND_ONLINE_SUCCESS事件，这个事件携带的包是
GetFriendOnlineReplyPacket，可用的字段如下:
position: byte, 下一个请求包的起始位置
onlineFriends: List，FriendOnlineEntry类的列表
失败时
尚未有操作失败事件的定义，因为我不知道如何才是失败，这么久了，这个操作就从没失败过，所以我
不知道失败的包是什么样子的。
狂迷 2005-10-28 14:26:59
Keep Alive
Keep Alive这个包，用来使QQ服务器知道自己还在线，至于到底你多久不发Keep Alive就认为你不在线
，这个还不清楚，感觉好像挺长的一段时间不发都没事，所以服务器端到底有没有真的在意这个包，我
说不准，QQ自己是1分钟发一次 的，建议实现你自己的程序的时候参考这个间隔，你要2分钟发一次，当
然也可以。这个包本身的作用很小，只能用来得到QQ总在线人数，它最主要的作用还是起 到一个定时器
的用处，你可以顺便在Keep Alive之后做一些事情，比如得到在线好友数，得到群在线成员数，都可以
在这个包之后做，so，把他当成一个固定操作的触发手段吧。
请求包格式
头部
用户QQ号的字符串形式
尾部
回复包格式
头部
6个域，分别是"0", "0", 所有在线用户数，我的IP，我的端口，未知含义字段，用ascii码31分隔
尾部
成功时
操作成功时，核心层会触发QQ_KEEP_ALIVE_SUCCESS事件，这个事件携带的包是KeepAliveReplyPacket，
可用的字段如下:
onlines: int, 总在线人数
ip: String, 我的外部IP的字符串形式
port: int, 我的外部端口
失败时
目前无失败事件定义，因为它从来就没失败过，所以也不知道失败的时候是什么样的
狂迷 2005-10-28 14:27:46
得到用户资料
查看用户资料是个很基本的功能了，用户资料有很多，这个就看QQ版本了，那么2004目前是包含了37个
字段，如果是2004 II，恐怕又会多些个性签名之类，你要是用2004 II的协议，自然是要与时俱进的。
请求包格式
头部
你想查看资料的用户QQ号的字符串形式
尾部
回复包格式
头部
用户资料，37个域，不管域的类型是整数还是什么，都采用字符串形式表示。每个域之间用字符'0'分隔
。这30个域的顺序你不用关心，他们都被包装在了edu.tsinghua.lumaqq.qq.beans.ContactInfo类中
尾部
成功时的事件
操作成功时，核心层会触发QQ_GET_USER_INFO_SUCCESS事件，这个事件携带的包是
GetUserInfoReplyPacket，可用的字段如下:
contactInfo: ContactInfo对象
失败时的事件
操作失败时，核心层会触发QQ_GET_USER_INFO_FAIL事件，这个事件携带的包是GetUserInfoReplyPacket
，无可用字段
狂迷 2005-10-28 14:28:23
登出
退出QQ，要发送Logout命令，这个命令是不需要等待回复的，也就是说你发了之后就可以退出程序了，
那么为了保证服务器能够收到你的登出命令，你需要 多发几次，比如像QQ的做法是发送4次，你想发多
少次就随便你了，我觉得这个也不是强制要做的，比如你只想发一次，也行，服务器收不到就收不到吧
，影响也 不大，说不定还能继续长你在线时间呃。
请求包格式
头部，包序号需要指定为0xFFFF，但是这个只是QQ的做法，指定为其他的是否可以，没有试验过，你感
兴趣可以试试
用session key加密的password key
尾部
这个包没有回复包，所以也没有相关联的事件了。
狂迷 2005-10-28 14:28:56
查找用户
QQ有很多种查找方式，这里是最简单的一种查找方式，2004版本开始有了高级查找，我们后面再介绍。
以前我们只能查找全部在线用户，或者根据用户的一些特定信息查找（叫做自定义查找)。所以这个命令
又包含两种搜索方式。
请求包格式
搜索方式的相关常量如下:
QQ_SEARCH_ALL: 查找全部在线用户
QQ_SEARCH_CUSTOM: 自定义查找
搜索方式为QQ_SEARCH_ALL时:
头部
搜索方式，1字节
1字节分隔符: 0x1F
页号的十进制字符串形式，从0开始。你应该知道在线用户是很多的，所以要分成多页来显示。实际上这
个页号是否真的有用也不好说，你如果不停的请求得到第0 页的用户，你会发现返回结果都不一样，所
以，这个页号有没有用很难说，不知道服务器是怎么做的。按照常理呢，你还是在程序中递增这个页号
吧。
尾部
搜索方式为QQ_SEARCH_CUSTOM时:
头部
搜索方式，1字节
1字节分隔符: 0x1F
要搜索的用户的QQ号的字符串形式
1字节分隔符: 0x1F
要搜索的用户的昵称
1字节分隔符: 0x1F
要搜索的用户的email
1字节分隔符: 0x1F
页号的字符串形式
1个字节，0x00，应该是结束符吧，因为前面是页号，考虑c语言的字符串表示方式，这个应该是页号的
结束符
尾部
对于那些不存在的条件，把这个字段置为空就是了
回复包格式
搜索的结果，有两种情况，一种是搜到了一些用户，一种是没搜到，这好像是废话哈？嗯，那么重要的
是这种结果之后的含义，没搜到简单啊，那你就应该停止发送搜索请求了。要是搜到了呢？还继续搜不
？这个当然就看你自己了，你想继续就继续，但是要记得把页号加1。
没搜到时：
头部
字符串"-1"，变成16进制就是0x2D31
尾部
搜到时:
头部
用户的资料，每个用户有4个字段，字段的顺序是"QQ号，昵称，地区，头像号码"，注意这些字段都是字
符串形式。所以为了分隔这些字段，同时为了分隔这些 用户，这里面有两种分隔符：0x1F用来分隔用户
，0x1E用来分隔用户的4个字段。要注意的是边界的情况，因为头像号码是最后一个字段，所以头像号码
后 面不是0x1E而是0x1F。那么自然QQ号前面也是0x1F。另外，第一个用户前面没有0x1F。搜索的结果被
封装在 edu.tsinghua.lumaqq.qq.beans.UserInfo中，一个用户对应一个UserInfo。
尾部
成功时
操作成功时，核心层会触发QQ_SEARCH_USER_SUCCESS事件，这个事件携带的包是SearchUserReplyPacket
，可用的字段如下:
finished: boolean, true表示后面还可能有更多的匹配，你应该页号加1继续搜
users: java.util.List，里面存放的是UserInfo对象
搜索结束时
操作成功时，核心层会触发QQ_SEARCH_USER_END事件，这个事件携带的包是SearchUserReplyPacket，可
用的字段如下:
finished: boolean, 既然是搜索结束，这个字段当然是true
失败时
因为目前未知还没失败过，所以不知道失败时候的模样，自然也没有失败的事件了
========
