简介资源为热血江湖游戏LoginTool登录服务器的完整C#源码工程面向网络游戏服务端开发学习者帮助理解经典MMORPG的登录认证与会话管理机制。包内共50个文件以cs源码、resx界面资源、dll依赖库及exe可执行程序为主另有sln工程文件、config配置文件、pfx签名证书和调试pdb符号整体约928KB结构清晰便于直接编译与二次学习。已有923人学习下载。通过阅读LoginTool源码可掌握账号身份验证、登录安全限制、会话标识分配、数据加密传输、并发请求处理以及异常日志记录等关键模块的实现思路结合界面交互代码与服务端连接逻辑还能了解登录服务器与游戏客户端之间的通信流程适合具备一定C#与网络编程基础、希望深入游戏服务端架构的开发者研读。1. 为什么 LoginTool 能卡住热血江湖 LS 源码的登录入口很多人拿到热血江湖 LS 源码后第一眼会去看账号表和网关配置想弄清楚登录器是怎么连上 LS 的。可真到自己调试时卡住他们的往往不是数据库而是 LoginTool 这一层客户端连不上、登录器转圈、版本校验不过、公告拉不下来。LoginTool 是登录器和 LS 之间的第一个协议接口账号密码、服务器列表、公告、客户端版本全在这条链路上走。要做热血江湖 LS 源码的调试和二次开发先把 LoginTool 的登录流程读透比改任何一行游戏逻辑都值。这一篇不讲怎么搭一套全量服务端而是聚焦 LoginTool 对应 LS 源码里那几条关键链路协议封包、认证状态机、超时重连、安全校验。适合刚拿到源码不知道从哪下手的开发也适合想给登录器加功能又怕改崩协议的老手。2. 读 LS 源码前先看协议LoginTool 的登录状态机2.1 从 LoginAuthReq 到 AuthResult报文怎么分包在 LS 源码里登录器不是一个 GUI 工程那么简单。LoginTool 启动后先读取网关配置再与 LS 建立一个 TCP 连接随后按固定顺序发送认证、心跳、拉取公告、请求角色列表。LS 侧则按照命令字路由到不同处理函数。这一步如果命令字对不上或者包长算错登录器会一直停留在“连接中”。常见的包结构是包头加可变长 body。我在调试这套源码时定义过这样一个最小包头#pragma pack(push, 1) struct LoginPacketHeader { uint16_t cmd; // 命令字例如 0x1001 表示登录请求 uint16_t len; // 整个包长度包含 header 自身 uint32_t seq; // 客户端自增序号 uint32_t session; // LS 下发的会话 id首次握手填 0 }; struct LoginAuthReq { LoginPacketHeader header; char account[32]; char password[32]; uint8_t version[4]; // 主/次/修订/内部号 uint32_t client_time; // 客户端时间戳 }; #pragma pack(pop)这段代码里有几个关键点#pragma pack(push, 1)是为了取消结构体对齐保证sizeof(LoginPacketHeader)按 2244 12 字节计算而不是被编译器对齐到 16 字节。登录器与服务端在 Windows 上用 VS 编译时可能还好换到 Linux 上用 g 编译对齐规则不一致很容易导致包体错位。cmd是登录协议的核心。这个字段偏移不对LS 侧收到一个错误命令字通常表现为服务端直接断开连接或者客户端一直收不到AuthResult。seq用来匹配请求和响应在高并发登录时特别重要。session则是 LS 在第一次握手后下发的临时会话标识后续的公告请求、角色列表都要带上它。在LoginAuthReq里版本号我建议拆成四个字段而不是一个字符串。原因很简单LS 源码中判断客户端版本基本都是逐段比较比如version[0] ! CLIENT_MAIN_VERSION就直接返回VERSION_MISMATCH。如果版本号存在字符串里还要多做一次解析而且字符串末尾的\0位置一旦没处理好就会把整包长度带偏。LS 收到LoginAuthReq后经过数据库校验会给 LoginTool 回一个AuthResult结构上一般包含结果码、角色列表、LS 时间、网关 IP 和端口。这里有一个容易忽略的字段LS 时间。客户端会用这个时间与本地时间做差值用于后续封包里的时间戳校验。如果调试时客户端机器时间与 LS 所在机器相差超过 5 分钟很多 LS 源码默认直接拒绝登录。提示修改结构体后一定要把sizeof(LoginPacketHeader)打印出来确认。十几个模块共用一个头文件时漏改一处就会让整条链路全部错位。2.2 登录状态机CLOSED、AUTHING 到 AUTH_OK登录器不能把登录当成一次请求就能完成。实际 LS 源码里的登录链路至少包含连接建立、握手、认证、心跳、公告拉取。任何一个环节失败都要回到CONNECTING状态重来。把状态机理清是最快的读码方式下面这张表描述每种状态下的行为和失败去向状态触发时机LoginTool 行为失败后的去向CLOSED初始化读取配置准备 socket报配置错误退出CONNECTING点击登录connect 网关端口重试超过次数后退出AUTHINGTCP 连接成功发送 LoginAuthReq回到 CONNECTINGWAIT_HANDSHAKE收到握手 challenge计算带盐哈希并回发回到 AUTHINGAUTH_OK收到 AuthResult拉取公告和角色列表进入游戏网关AUTH_FAIL收到错误码在界面显示原因回到 CLOSEDRECONNECTING心跳超时保留 account重新连接同样回到 CLOSED这张表的价值在于它能告诉你调试时该看哪个日志。比如状态停在CONNECTING优先查网络和端口停在AUTHING优先查版本号和账号密码格式停在WAIT_HANDSHAKE基本就是加密算法和盐不一致。很多新手一上来就查数据库结果数据库没问题问题出在挑战码的盐在服务端是动态生成的LoginTool 里却写死了旧盐。响应码也值得整理成常量避免在代码里散落魔数。常见的 LS 响应码如下结果码含义LoginTool 提示文案0登录成功无1账号不存在账号或密码错误2密码错误账号或密码错误3客户端版本过低请更新客户端4服务器人数已满请稍后再试5账号被封禁联系客服6挑战码过期重新登录注意结果码一旦是 6LoginTool 不需要弹“登录失败”而应该静默回到CONNECTING重新发起握手。这类状态码在 LS 源码里大多是个枚举我一般会先将枚举和文案对齐再往上做界面逻辑。否则服务端加了一个新结果码登录器文案还是旧的玩家只看到一句“错误”问题很难定位。2.3 用 Wireshark 抓一次登录把命令字和 seq 对齐如果代码看到一半仍然不确定命令字直接抓包最省事。捕获过滤器填tcp.port 12000然后点一次登录观察前四个 TCP 段。第一个是 SYN第二个是 SYN-ACK第三个是 ACK第四个开始才是业务包。如果第四个包的长度不是 12 加账号体说明包头定义和实际发送不一致。为了验证拆包逻辑我一般会先写一段最小的 Python 解析器把 LS 发过来的流式 TCP 数据切成一个个包import socket, struct def recv_exact(sock: socket.socket, size: int) - bytes: data b while len(data) size: chunk sock.recv(size - len(data)) if not chunk: raise ConnectionError(connection closed) data chunk return data def recv_packet(sock: socket.socket): header recv_exact(sock, 12) cmd, total_len, seq, session struct.unpack(HHII, header) body recv_exact(sock, total_len - 12) return cmd, seq, session, bodyrecv_exact解决半包问题total_len防止粘包后读越界。这里要注意字节序struct.unpack(HHII, header)是小端解析对应 Windows 上常见的 x86 结构体如果 LS 源码里把包头发成网络字节序就要改成HHII。用这段代码把服务端日志里的原始字节流打印出来确认服务端发的是0x1001还是0x0101比在代码里猜快得多。3. 跑通 LoginToolLS 源码目录、构建命令与首发验证3.1 从目录结构识别 LoginTool 的依赖拿到一套热血江湖 LS 源码第一件事不是直接编译而是先看目录名。我一般会直接搜索LoginTool或Launcher然后把它的头文件引用列出来看它依赖了哪几个模块。下面是一个比较常见的布局install/ ├─ Common/ │ ├─ base64.c │ ├─ md5.c │ └─ log.c ├─ Network/ │ ├─ socket_wrapper.c │ └─ packet_queue.c ├─ Database/ │ └─ account_db.c ├─ LoginServer/ │ ├─ main.c │ └─ login_handler.c ├─ Tool/ │ └─ LoginTool/ │ ├─ main.c │ ├─ ui/ # 界面资源 │ └─ config.txt └─ Config/ └─ Gateway.ini这个布局在很多老游戏源码里都能看到Common放通用工具Network放封包Database放账号相关Tool放登录器。Common听起来像公共代码但在 LoginTool 里它的加密和日志函数是要单独编译进去的不能只依赖动态库。有些源码把Common编译成静态库到了 LoginTool 的工程文件里却没有链接登录器一运行就崩溃。老源码对大小写很敏感。Linux 下#include Common/md5.h和#include common/MD5.h是两回事。编译报找不到头文件时先别急着改代码检查头文件路径里的大小写和分隔符。Windows 下的源码经常用\作为包含路径分隔符拿到 Linux 上要统一改成/。3.2 网关地址、端口和版本号写在哪接下来找配置文件。LoginTool 一般不会把网关地址写死而是放到config.txt或Gateway.ini。这个文件里最核心的是下面几个键[Gateway] IP 127.0.0.1 Port 12000 RetryCount 3 RetryInterval 2 TimeDelta 300 PublicKey MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ... ClientVersion 1.0.0.72对应的参数含义如下配置项示例作用IP127.0.0.1LS 监听地址跨机器时填内网 IPPort12000LS 端口必须与 LoginServer.ini 一致RetryCount3TCP 连接失败后的重试次数RetryInterval2每次重试间隔单位秒TimeDelta300允许的本地时间与 LS 时间差单位秒PublicKeyMIGf...RSA 公钥用于加密密码传输ClientVersion1.0.0.72客户端版本和 LS 校验的版本号对应TimeDelta这个值常被忽视。很多登录器只把它当作时钟同步偏差但 LS 源码往往会把它同时用于挑战码过期判断。挑战码在安全要求高的源码里不会只存一个时间戳而是“时间戳加随机串加会话ID”三合一。LoginTool 如果只是回传固定盐时间一长就会被重放攻击这个问题在 4.2 节会展开。PublicKey是公钥不是私钥。登录器只负责用公钥加密私钥留在 LS 上。如果登录器里出现了PrivateKey字样说明这版源码的密钥分发方式有问题或者说这套源码只适合内网调试不能直接放到公网。3.3 最小构建命令与首发日志目录和配置确认后构建就是一个 CMake 命令的问题。假设源码根目录有CMakeLists.txt我一般会开一个干净的 build 目录mkdir -p build cd build cmake .. -DCMAKE_BUILD_TYPERelease -DTARGETLoginTool make -j4 ./LoginTool --config ../Config/Gateway.ini如果不支持 CMake就退到源码根目录的 Makefile直接make LoginTool。这里不推荐在源码根目录直接 make因为很多老工程会把中间文件生成在源码树里改坏一个.o就得全清。编译通过后启动 LoginTool观察 stderr 和日志文件。正常情况应该能依次看到这几行[2025-03-01 10:00:01] [INFO] login_tool: load config ok [2025-03-01 10:00:02] [INFO] login_tool: connecting 127.0.0.1:12000 [2025-03-01 10:00:02] [INFO] login_tool: auth_req sent, seq1 [2025-03-01 10:00:02] [INFO] login_tool: auth_ack recv, seq1, code0看到seq1和code0才算真正跑通。如果卡在connecting就去查防火墙和 LS 的监听端口如果卡在auth_req sent后面没有auth_ack多半是包长或命令字有问题用第 2 章的拆包函数抓一下 LS 回包对比协议定义。首发验证不光是能连上而是要确认 seq 能配对、code 能解析、时间差能通过。4. 上线前要动的三处代码MD5 加盐、令牌校验和公告下发4.1 口令加密别再做一次拼接 MD5很多老源码里的登录器是零几年写的密码直接md5(password)就发出去。虽然数据库里存的是密文但字典库太容易撞了。我一般会在 LS 源码里加一道盐让 LoginTool 侧改成这样std::string build_password_hash(const std::string password, const std::string salt) { // 盐放进密码前而不是后拼接避免常见字典 std::string raw salt password; return md5_hex(raw); }为什么盐放前面纯属约定。前后都能用关键是一旦定下来服务端account_db.c里的校验函数必须同步改否则登录器发过去的新哈希和数据库里的旧哈希永远对不上。更稳的做法是 LS 在握手时下发一个随机盐LoginTool 用这个动态盐去算而不是写死在配置文件里。服务端校验时还要防止时序攻击。常见做法是先将结果转为十六进制字符串再用memcmp比较。不要用strcmp因为strcmp遇到\0会提前结束而且长度不同的字符串也能被观察出来。只要直接比较 MD5 摘要的字节数组并保证两个缓冲区长度相同就能避免大部分问题。当然这层只是第一道真正要防的是重放。4.2 Challenge-Response时间戳加随机数只加盐还挡不住重放。抓包的人把account hash原样再发一遍登录器还是会通过。所以大多数 LS 源码会在握手后发一个 challengeLS - LoginTool: {challenge: 3F92A8C1, salt: 7K3x, expires: 1751234567} LoginTool - LS: {account, response: md5(salt password challenge)}LoginTool 收到 challenge 后不能直接把它和密码拼一起而是要把 challenge 当成一次性令牌。LS 在内存里维护一个 challenge 缓存并记录生成时间和会话号。校验通过后立即清除。这样同一个 challenge 只能使用一次。相应地LoginTool 侧要做的改动有两个一是把LoginAuthReq里原来的password字段改成response并在握手之后再用这个字段二是发完response后等AuthResult时要有超时机制比如 3 秒没收到就丢弃本地 challenge重新发起握手。这里给一组校验超时参数参考参数建议值说明CHALLENGE_LEN16 字节随机串长度太短容易被碰撞CHALLENGE_TTL30 秒超过后服务端拒绝RESPONSE_TIMEOUT3 秒LoginTool 等待 AuthResult 的超时RETRY_MAX2 次Challenge 失败后的重试上限这些参数不要直接埋在代码里放到配置文件中方便 LS 和 LoginTool 两端对齐。尤其是CHALLENGE_TTL调太短会导致部分玩家在弱网下反复失败调太长又给了重放窗口。我一般先给 30 秒压测后再压缩。提示challenge 一旦使用过必须立即从缓存里删除不能只在过期后清理。4.3 公告和开服列表从 LS 拉还是从 HTTP 拉登录器除了认证还要显示公告和服务器列表。常见做法是 LS 在AuthResult里直接返回一段文本或 URL但更好的做法是让 LoginTool 访问一个独立的 HTTP 接口避免公告内容过长撑爆登录包。在 LS 源码里注册一个 HTTP 服务并不难这里用一段 shell 命令测试接口是否可用curl -s http://127.0.0.1:8080/serverlist.json | jq .返回示例{ servers: [ {name: 经典一区, ip: 192.168.1.10, port: 12000, status: hot} ], notice: 维护通知 }为什么把服务器列表也放到 HTTP因为 LoginTool 的登录包长度是固定的像LoginAuthReq里的account[32]如果被塞满装不下服务器列表。HTTP 接口还能单独做分发公告更新不用重启 LS也不会因为登录包过大被防火墙丢弃。代价就是 LoginTool 要多维护一个 HTTP 客户端状态和 LS 主协议的 TCP 状态机互相独立。如果 LS 源码里没有 HTTP 服务可以直接让 LS 在AuthResult后面追加一个NoticeMsg包命令字单独定义LoginTool 的拆包函数里加一个分支即可。这个做法仍然要遵循第 2 章的 seq 机制避免公告包和认证响应包乱序。5. 验证 LoginTool 可靠性的 3 个压测技巧第一个技巧是用asyncio批量模拟登录。下面是一段最小可跑的压测结构没有处理挑战码和心跳但足以暴露连接数、端口、命令字的问题import asyncio, struct, hashlib def build_auth_req(seq, account, password): ver bytes([1, 0, 0, 72]) # 简化版仅用于本地压测 body account.encode().ljust(32, b\0) body hashlib.md5(password.encode()).hexdigest().encode() body ver return struct.pack(HHII, 0x1001, 12 len(body), seq, 0) body async def login_once(account, password): reader, writer await asyncio.open_connection(127.0.0.1, 12000) writer.write(build_auth_req(1, account, password)) await writer.drain() header await reader.readexactly(12) cmd, total_len, seq, session struct.unpack(HHII, header) body await reader.readexactly(total_len - 12) return seq, body async def load_test(n): for i in range(n): try: await login_once(fu{i}, 123456) except Exception as exc: print(i, exc) asyncio.run(load_test(500))这段代码的重点是reader.readexactly它能严格保证包头读满 12 字节。如果 LS 在 500 个并发里出现几十个Connection closed基本可以断定是服务端 backlog 或线程池不够而不是登录器逻辑问题。第二个技巧是模拟弱网。压测前在本地回环上加上丢包和延迟观察 LoginTool 的RECONNECTING状态是否正常sudo tc qdisc add dev lo root netem loss 10% delay 300ms # 压测结束后清理 sudo tc qdisc del dev lo root加了延迟后重点看心跳超时时间。如果HeartbeatInterval是 30 秒但tc delay 300ms就能触发掉线说明重试逻辑里没有考虑网络抖动需要把心跳发送间隔和 TCP 超时分开配置。第三个技巧是盯着日志里的 seq 找瓶颈。无论压测结果好坏都要把所有请求的 seq、耗时、结果码落成三列 CSV。压测完成后统计seq的乱序比例和code ! 0的分布。如果乱序比例高说明服务端并发处理线程没有按请求顺序回包如果超时集中在某个时间段说明网关 CPU 到顶了。把 seq 不连续的记录拉出来按时间戳对齐看看是公网延迟导致的重传还是 LS 线程池处理不过来。找到问题后再回到 4.2 的挑战码缓存表调 TTL这才是压测的意义不是跑出个 ok/total 就完事。本文还有配套的精品资源点击获取 热血江湖LS源码登录流程解析：从LoginTool协议封包到压测实践
简介资源为热血江湖游戏LoginTool登录服务器的完整C#源码工程面向网络游戏服务端开发学习者帮助理解经典MMORPG的登录认证与会话管理机制。包内共50个文件以cs源码、resx界面资源、dll依赖库及exe可执行程序为主另有sln工程文件、config配置文件、pfx签名证书和调试pdb符号整体约928KB结构清晰便于直接编译与二次学习。已有923人学习下载。通过阅读LoginTool源码可掌握账号身份验证、登录安全限制、会话标识分配、数据加密传输、并发请求处理以及异常日志记录等关键模块的实现思路结合界面交互代码与服务端连接逻辑还能了解登录服务器与游戏客户端之间的通信流程适合具备一定C#与网络编程基础、希望深入游戏服务端架构的开发者研读。1. 为什么 LoginTool 能卡住热血江湖 LS 源码的登录入口很多人拿到热血江湖 LS 源码后第一眼会去看账号表和网关配置想弄清楚登录器是怎么连上 LS 的。可真到自己调试时卡住他们的往往不是数据库而是 LoginTool 这一层客户端连不上、登录器转圈、版本校验不过、公告拉不下来。LoginTool 是登录器和 LS 之间的第一个协议接口账号密码、服务器列表、公告、客户端版本全在这条链路上走。要做热血江湖 LS 源码的调试和二次开发先把 LoginTool 的登录流程读透比改任何一行游戏逻辑都值。这一篇不讲怎么搭一套全量服务端而是聚焦 LoginTool 对应 LS 源码里那几条关键链路协议封包、认证状态机、超时重连、安全校验。适合刚拿到源码不知道从哪下手的开发也适合想给登录器加功能又怕改崩协议的老手。2. 读 LS 源码前先看协议LoginTool 的登录状态机2.1 从 LoginAuthReq 到 AuthResult报文怎么分包在 LS 源码里登录器不是一个 GUI 工程那么简单。LoginTool 启动后先读取网关配置再与 LS 建立一个 TCP 连接随后按固定顺序发送认证、心跳、拉取公告、请求角色列表。LS 侧则按照命令字路由到不同处理函数。这一步如果命令字对不上或者包长算错登录器会一直停留在“连接中”。常见的包结构是包头加可变长 body。我在调试这套源码时定义过这样一个最小包头#pragma pack(push, 1) struct LoginPacketHeader { uint16_t cmd; // 命令字例如 0x1001 表示登录请求 uint16_t len; // 整个包长度包含 header 自身 uint32_t seq; // 客户端自增序号 uint32_t session; // LS 下发的会话 id首次握手填 0 }; struct LoginAuthReq { LoginPacketHeader header; char account[32]; char password[32]; uint8_t version[4]; // 主/次/修订/内部号 uint32_t client_time; // 客户端时间戳 }; #pragma pack(pop)这段代码里有几个关键点#pragma pack(push, 1)是为了取消结构体对齐保证sizeof(LoginPacketHeader)按 2244 12 字节计算而不是被编译器对齐到 16 字节。登录器与服务端在 Windows 上用 VS 编译时可能还好换到 Linux 上用 g 编译对齐规则不一致很容易导致包体错位。cmd是登录协议的核心。这个字段偏移不对LS 侧收到一个错误命令字通常表现为服务端直接断开连接或者客户端一直收不到AuthResult。seq用来匹配请求和响应在高并发登录时特别重要。session则是 LS 在第一次握手后下发的临时会话标识后续的公告请求、角色列表都要带上它。在LoginAuthReq里版本号我建议拆成四个字段而不是一个字符串。原因很简单LS 源码中判断客户端版本基本都是逐段比较比如version[0] ! CLIENT_MAIN_VERSION就直接返回VERSION_MISMATCH。如果版本号存在字符串里还要多做一次解析而且字符串末尾的\0位置一旦没处理好就会把整包长度带偏。LS 收到LoginAuthReq后经过数据库校验会给 LoginTool 回一个AuthResult结构上一般包含结果码、角色列表、LS 时间、网关 IP 和端口。这里有一个容易忽略的字段LS 时间。客户端会用这个时间与本地时间做差值用于后续封包里的时间戳校验。如果调试时客户端机器时间与 LS 所在机器相差超过 5 分钟很多 LS 源码默认直接拒绝登录。提示修改结构体后一定要把sizeof(LoginPacketHeader)打印出来确认。十几个模块共用一个头文件时漏改一处就会让整条链路全部错位。2.2 登录状态机CLOSED、AUTHING 到 AUTH_OK登录器不能把登录当成一次请求就能完成。实际 LS 源码里的登录链路至少包含连接建立、握手、认证、心跳、公告拉取。任何一个环节失败都要回到CONNECTING状态重来。把状态机理清是最快的读码方式下面这张表描述每种状态下的行为和失败去向状态触发时机LoginTool 行为失败后的去向CLOSED初始化读取配置准备 socket报配置错误退出CONNECTING点击登录connect 网关端口重试超过次数后退出AUTHINGTCP 连接成功发送 LoginAuthReq回到 CONNECTINGWAIT_HANDSHAKE收到握手 challenge计算带盐哈希并回发回到 AUTHINGAUTH_OK收到 AuthResult拉取公告和角色列表进入游戏网关AUTH_FAIL收到错误码在界面显示原因回到 CLOSEDRECONNECTING心跳超时保留 account重新连接同样回到 CLOSED这张表的价值在于它能告诉你调试时该看哪个日志。比如状态停在CONNECTING优先查网络和端口停在AUTHING优先查版本号和账号密码格式停在WAIT_HANDSHAKE基本就是加密算法和盐不一致。很多新手一上来就查数据库结果数据库没问题问题出在挑战码的盐在服务端是动态生成的LoginTool 里却写死了旧盐。响应码也值得整理成常量避免在代码里散落魔数。常见的 LS 响应码如下结果码含义LoginTool 提示文案0登录成功无1账号不存在账号或密码错误2密码错误账号或密码错误3客户端版本过低请更新客户端4服务器人数已满请稍后再试5账号被封禁联系客服6挑战码过期重新登录注意结果码一旦是 6LoginTool 不需要弹“登录失败”而应该静默回到CONNECTING重新发起握手。这类状态码在 LS 源码里大多是个枚举我一般会先将枚举和文案对齐再往上做界面逻辑。否则服务端加了一个新结果码登录器文案还是旧的玩家只看到一句“错误”问题很难定位。2.3 用 Wireshark 抓一次登录把命令字和 seq 对齐如果代码看到一半仍然不确定命令字直接抓包最省事。捕获过滤器填tcp.port 12000然后点一次登录观察前四个 TCP 段。第一个是 SYN第二个是 SYN-ACK第三个是 ACK第四个开始才是业务包。如果第四个包的长度不是 12 加账号体说明包头定义和实际发送不一致。为了验证拆包逻辑我一般会先写一段最小的 Python 解析器把 LS 发过来的流式 TCP 数据切成一个个包import socket, struct def recv_exact(sock: socket.socket, size: int) - bytes: data b while len(data) size: chunk sock.recv(size - len(data)) if not chunk: raise ConnectionError(connection closed) data chunk return data def recv_packet(sock: socket.socket): header recv_exact(sock, 12) cmd, total_len, seq, session struct.unpack(HHII, header) body recv_exact(sock, total_len - 12) return cmd, seq, session, bodyrecv_exact解决半包问题total_len防止粘包后读越界。这里要注意字节序struct.unpack(HHII, header)是小端解析对应 Windows 上常见的 x86 结构体如果 LS 源码里把包头发成网络字节序就要改成HHII。用这段代码把服务端日志里的原始字节流打印出来确认服务端发的是0x1001还是0x0101比在代码里猜快得多。3. 跑通 LoginToolLS 源码目录、构建命令与首发验证3.1 从目录结构识别 LoginTool 的依赖拿到一套热血江湖 LS 源码第一件事不是直接编译而是先看目录名。我一般会直接搜索LoginTool或Launcher然后把它的头文件引用列出来看它依赖了哪几个模块。下面是一个比较常见的布局install/ ├─ Common/ │ ├─ base64.c │ ├─ md5.c │ └─ log.c ├─ Network/ │ ├─ socket_wrapper.c │ └─ packet_queue.c ├─ Database/ │ └─ account_db.c ├─ LoginServer/ │ ├─ main.c │ └─ login_handler.c ├─ Tool/ │ └─ LoginTool/ │ ├─ main.c │ ├─ ui/ # 界面资源 │ └─ config.txt └─ Config/ └─ Gateway.ini这个布局在很多老游戏源码里都能看到Common放通用工具Network放封包Database放账号相关Tool放登录器。Common听起来像公共代码但在 LoginTool 里它的加密和日志函数是要单独编译进去的不能只依赖动态库。有些源码把Common编译成静态库到了 LoginTool 的工程文件里却没有链接登录器一运行就崩溃。老源码对大小写很敏感。Linux 下#include Common/md5.h和#include common/MD5.h是两回事。编译报找不到头文件时先别急着改代码检查头文件路径里的大小写和分隔符。Windows 下的源码经常用\作为包含路径分隔符拿到 Linux 上要统一改成/。3.2 网关地址、端口和版本号写在哪接下来找配置文件。LoginTool 一般不会把网关地址写死而是放到config.txt或Gateway.ini。这个文件里最核心的是下面几个键[Gateway] IP 127.0.0.1 Port 12000 RetryCount 3 RetryInterval 2 TimeDelta 300 PublicKey MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ... ClientVersion 1.0.0.72对应的参数含义如下配置项示例作用IP127.0.0.1LS 监听地址跨机器时填内网 IPPort12000LS 端口必须与 LoginServer.ini 一致RetryCount3TCP 连接失败后的重试次数RetryInterval2每次重试间隔单位秒TimeDelta300允许的本地时间与 LS 时间差单位秒PublicKeyMIGf...RSA 公钥用于加密密码传输ClientVersion1.0.0.72客户端版本和 LS 校验的版本号对应TimeDelta这个值常被忽视。很多登录器只把它当作时钟同步偏差但 LS 源码往往会把它同时用于挑战码过期判断。挑战码在安全要求高的源码里不会只存一个时间戳而是“时间戳加随机串加会话ID”三合一。LoginTool 如果只是回传固定盐时间一长就会被重放攻击这个问题在 4.2 节会展开。PublicKey是公钥不是私钥。登录器只负责用公钥加密私钥留在 LS 上。如果登录器里出现了PrivateKey字样说明这版源码的密钥分发方式有问题或者说这套源码只适合内网调试不能直接放到公网。3.3 最小构建命令与首发日志目录和配置确认后构建就是一个 CMake 命令的问题。假设源码根目录有CMakeLists.txt我一般会开一个干净的 build 目录mkdir -p build cd build cmake .. -DCMAKE_BUILD_TYPERelease -DTARGETLoginTool make -j4 ./LoginTool --config ../Config/Gateway.ini如果不支持 CMake就退到源码根目录的 Makefile直接make LoginTool。这里不推荐在源码根目录直接 make因为很多老工程会把中间文件生成在源码树里改坏一个.o就得全清。编译通过后启动 LoginTool观察 stderr 和日志文件。正常情况应该能依次看到这几行[2025-03-01 10:00:01] [INFO] login_tool: load config ok [2025-03-01 10:00:02] [INFO] login_tool: connecting 127.0.0.1:12000 [2025-03-01 10:00:02] [INFO] login_tool: auth_req sent, seq1 [2025-03-01 10:00:02] [INFO] login_tool: auth_ack recv, seq1, code0看到seq1和code0才算真正跑通。如果卡在connecting就去查防火墙和 LS 的监听端口如果卡在auth_req sent后面没有auth_ack多半是包长或命令字有问题用第 2 章的拆包函数抓一下 LS 回包对比协议定义。首发验证不光是能连上而是要确认 seq 能配对、code 能解析、时间差能通过。4. 上线前要动的三处代码MD5 加盐、令牌校验和公告下发4.1 口令加密别再做一次拼接 MD5很多老源码里的登录器是零几年写的密码直接md5(password)就发出去。虽然数据库里存的是密文但字典库太容易撞了。我一般会在 LS 源码里加一道盐让 LoginTool 侧改成这样std::string build_password_hash(const std::string password, const std::string salt) { // 盐放进密码前而不是后拼接避免常见字典 std::string raw salt password; return md5_hex(raw); }为什么盐放前面纯属约定。前后都能用关键是一旦定下来服务端account_db.c里的校验函数必须同步改否则登录器发过去的新哈希和数据库里的旧哈希永远对不上。更稳的做法是 LS 在握手时下发一个随机盐LoginTool 用这个动态盐去算而不是写死在配置文件里。服务端校验时还要防止时序攻击。常见做法是先将结果转为十六进制字符串再用memcmp比较。不要用strcmp因为strcmp遇到\0会提前结束而且长度不同的字符串也能被观察出来。只要直接比较 MD5 摘要的字节数组并保证两个缓冲区长度相同就能避免大部分问题。当然这层只是第一道真正要防的是重放。4.2 Challenge-Response时间戳加随机数只加盐还挡不住重放。抓包的人把account hash原样再发一遍登录器还是会通过。所以大多数 LS 源码会在握手后发一个 challengeLS - LoginTool: {challenge: 3F92A8C1, salt: 7K3x, expires: 1751234567} LoginTool - LS: {account, response: md5(salt password challenge)}LoginTool 收到 challenge 后不能直接把它和密码拼一起而是要把 challenge 当成一次性令牌。LS 在内存里维护一个 challenge 缓存并记录生成时间和会话号。校验通过后立即清除。这样同一个 challenge 只能使用一次。相应地LoginTool 侧要做的改动有两个一是把LoginAuthReq里原来的password字段改成response并在握手之后再用这个字段二是发完response后等AuthResult时要有超时机制比如 3 秒没收到就丢弃本地 challenge重新发起握手。这里给一组校验超时参数参考参数建议值说明CHALLENGE_LEN16 字节随机串长度太短容易被碰撞CHALLENGE_TTL30 秒超过后服务端拒绝RESPONSE_TIMEOUT3 秒LoginTool 等待 AuthResult 的超时RETRY_MAX2 次Challenge 失败后的重试上限这些参数不要直接埋在代码里放到配置文件中方便 LS 和 LoginTool 两端对齐。尤其是CHALLENGE_TTL调太短会导致部分玩家在弱网下反复失败调太长又给了重放窗口。我一般先给 30 秒压测后再压缩。提示challenge 一旦使用过必须立即从缓存里删除不能只在过期后清理。4.3 公告和开服列表从 LS 拉还是从 HTTP 拉登录器除了认证还要显示公告和服务器列表。常见做法是 LS 在AuthResult里直接返回一段文本或 URL但更好的做法是让 LoginTool 访问一个独立的 HTTP 接口避免公告内容过长撑爆登录包。在 LS 源码里注册一个 HTTP 服务并不难这里用一段 shell 命令测试接口是否可用curl -s http://127.0.0.1:8080/serverlist.json | jq .返回示例{ servers: [ {name: 经典一区, ip: 192.168.1.10, port: 12000, status: hot} ], notice: 维护通知 }为什么把服务器列表也放到 HTTP因为 LoginTool 的登录包长度是固定的像LoginAuthReq里的account[32]如果被塞满装不下服务器列表。HTTP 接口还能单独做分发公告更新不用重启 LS也不会因为登录包过大被防火墙丢弃。代价就是 LoginTool 要多维护一个 HTTP 客户端状态和 LS 主协议的 TCP 状态机互相独立。如果 LS 源码里没有 HTTP 服务可以直接让 LS 在AuthResult后面追加一个NoticeMsg包命令字单独定义LoginTool 的拆包函数里加一个分支即可。这个做法仍然要遵循第 2 章的 seq 机制避免公告包和认证响应包乱序。5. 验证 LoginTool 可靠性的 3 个压测技巧第一个技巧是用asyncio批量模拟登录。下面是一段最小可跑的压测结构没有处理挑战码和心跳但足以暴露连接数、端口、命令字的问题import asyncio, struct, hashlib def build_auth_req(seq, account, password): ver bytes([1, 0, 0, 72]) # 简化版仅用于本地压测 body account.encode().ljust(32, b\0) body hashlib.md5(password.encode()).hexdigest().encode() body ver return struct.pack(HHII, 0x1001, 12 len(body), seq, 0) body async def login_once(account, password): reader, writer await asyncio.open_connection(127.0.0.1, 12000) writer.write(build_auth_req(1, account, password)) await writer.drain() header await reader.readexactly(12) cmd, total_len, seq, session struct.unpack(HHII, header) body await reader.readexactly(total_len - 12) return seq, body async def load_test(n): for i in range(n): try: await login_once(fu{i}, 123456) except Exception as exc: print(i, exc) asyncio.run(load_test(500))这段代码的重点是reader.readexactly它能严格保证包头读满 12 字节。如果 LS 在 500 个并发里出现几十个Connection closed基本可以断定是服务端 backlog 或线程池不够而不是登录器逻辑问题。第二个技巧是模拟弱网。压测前在本地回环上加上丢包和延迟观察 LoginTool 的RECONNECTING状态是否正常sudo tc qdisc add dev lo root netem loss 10% delay 300ms # 压测结束后清理 sudo tc qdisc del dev lo root加了延迟后重点看心跳超时时间。如果HeartbeatInterval是 30 秒但tc delay 300ms就能触发掉线说明重试逻辑里没有考虑网络抖动需要把心跳发送间隔和 TCP 超时分开配置。第三个技巧是盯着日志里的 seq 找瓶颈。无论压测结果好坏都要把所有请求的 seq、耗时、结果码落成三列 CSV。压测完成后统计seq的乱序比例和code ! 0的分布。如果乱序比例高说明服务端并发处理线程没有按请求顺序回包如果超时集中在某个时间段说明网关 CPU 到顶了。把 seq 不连续的记录拉出来按时间戳对齐看看是公网延迟导致的重传还是 LS 线程池处理不过来。找到问题后再回到 4.2 的挑战码缓存表调 TTL这才是压测的意义不是跑出个 ok/total 就完事。本文还有配套的精品资源点击获取