对接某短视频开放平台的时候我翻过对方接口包里的加密逻辑后来照着这套思路整理出了一个可以通用的多模块加密系统。它不是单一加密函数那么简单内部拆了四个模块Token模块管身份和时效签名模块管完整性和来源数据加密模块管机密性Gzip压缩模块管体积。标题里写的“从Token到Gzip”其实就是这套系统完整链路的两端。这篇文章我把整个设计思路、每个模块的实现细节、以及实际调试里踩过的坑一起梳理出来希望对正在做接口安全、客户端数据保护或网络框架的开发者有些参考价值。1. 项目背景与模块边界划分1.1 这套系统要解决的核心问题服务端和客户端之间传输的数据既要防窃听、防篡改又不能因为加密导致带宽和延迟爆炸。我这边实际接手的是某短视频开放平台的接口对接项目对方客户端发的每个请求都带一串特征明显的Tokenbody部分是一段不可读的Base64字符串剥开之后能明显看到压缩和加密叠加的痕迹。如果不拆开理解单独看任何一个模块都看不懂它是怎么串起来的更别说在自己系统里复刻一套。这其实是当下接口安全设计的常见套路单靠一个链路层加密只是扛住了传输过程应用层数据本身还是明文被代理工具一抓包就全露馅。所以这套系统的目标是把应用层数据本身做成“黑盒”同时保证黑盒不能太大否则移动端流量吃不消。1.2 四个模块的边界划分我见过很多半吊子方案用一句话概括就是“加密就完事了”但真正要认真设计得弄清楚四个问题各自被谁解决模块要解决的核心问题常见算法/工具失败时的典型表现Token模块你是谁、当前请求是否仍有效HMAC-SHA256、JWT风格自定义结构401鉴权失败、token过期无法刷新签名模块数据是不是你发的、有没有被改动HMAC、RSA-SHA256服务端验签不通过、body被篡改数据加密模块即使数据被截获也看不懂真实内容AES-GCM密文被解密出明文、内容泄露Gzip压缩模块加密前先把体积降下来减少带宽gzip、deflate流量过大、传输耗时翻倍这里的核心思路是职责单一。Token是身份的“门禁卡”签名是数据的“防拆封条”加密是内容的“保密箱”压缩是快递的“真空包装”。四件事看似都和数据安全有关但关注点完全不同拆开才能独立演进。1.3 为什么坚持拆分成多模块我项目第一版就是图省事把密钥管理、token生成、参数签名、加解密全部堆在一个工具类里。当时觉得系统小用不着高大上的分层。结果第一次做密钥轮换就翻车了改密钥默认有效期的时候顺手动了AES密钥的轮换逻辑上线后高版本客户端全部解密失败回滚花了将近两小时。拆模块之后的好处非常直接每个模块的接口稳定改动局部化。token校验逻辑和加解密逻辑不互相污染。每个模块可以单独写单元测试、单独压测。将来换成不同算法时不需要动其他模块。这个取舍你得自己体会。总想着“先跑起来再说”没问题但如果预判到系统要长期维护边界从一开始就应该划清楚。2. Token模块深度解析2.1 Token结构与生成流程我在两个项目里见到的Token结构基本一致都是三段式header.payload.signature。这种结构的好处是解包时不需要查存储服务端拿到Token就能独立校验。header里通常放算法标识、token类型和版本号我一般是这样组织的{ alg: HS256, typ: JWT, kid: 20250101 }payload里放用户标记、scope权限范围、签发时间、过期时间等业务必要字段{ sub: user_123456, scope: app:read app:write, iat: 1740123456, exp: 1740130656 }签名部分是把前两段拼接后做HMAC-SHA256得到的。关键是怎么防止前两段被篡改把header和payload分别做Base64URL编码中间用点号拼接再用密钥做HMAC最后把结果附在后面。Python的生成代码很简单import base64 import hashlib import hmac import json import time SECRET_KEY byour-256-bit-secret-here def base64url_encode(data: bytes) - str: return base64.urlsafe_b64encode(data).rstrip(b).decode(ascii) def base64url_decode(data: str) - bytes: padding * (-len(data) % 4) return base64.urlsafe_b64decode(data padding) def generate_token(user_id: str, expires_in: int 7200) - str: header {alg: HS256, typ: JWT, kid: 20250101} payload { sub: user_id, iat: int(time.time()), exp: int(time.time()) expires_in, } header_seg base64url_encode(json.dumps(header, separators(,, :)).encode()) payload_seg base64url_encode(json.dumps(payload, separators(,, :)).encode()) signing_input f{header_seg}.{payload_seg}.encode() signature hmac.new(SECRET_KEY, signing_input, hashlib.sha256).digest() signature_seg base64url_encode(signature) return f{header_seg}.{payload_seg}.{signature_seg}这里要提醒一个细节base64.urlsafe_b64encode默认会带填充Token里不应该有这些字符必须去掉。2.2 签名算法选型HMAC-SHA256还是RSA算法选型是Token模块里最容易被忽略的决策。HS256HMAC-SHA256是对称签名签发和校验用同一个密钥速度快、实现简单。RS256RSA-SHA256是非对称签名私钥签发、公钥校验适合第三方开放平台场景。我自己的判断标准是服务端自己签发、自己校验选HS256CPU开销小密钥管理简单。将来要开放给第三方接入选RS256或ES256因为私钥不下发公钥可以公开。如果你要发行的客户端本身会被逆向密钥藏在哪里都是问题这时候需要配合白盒加密或硬件安全模块单纯选算法解决不了。标题里说的“抖音Token”这类平台Token走的就是JWT风格但在签名细节上每家都会做定制例如在payload里塞自己的设备指纹字段或者把签名密钥分成两级。你在逆向分析时不要只看标准库能解出来的部分还要注意自定义字段的校验逻辑。2.3 过期时间、刷新机制与时钟偏移处理单Token过期时间设太短用户频繁登录体验差设太长Token泄露后的风险窗口又太大。工程上通常采用双Token机制access token短期凭证有效期2小时放在每个业务请求的header里。refresh token长期凭证有效期14天只在刷新接口使用必须配合设备指纹和续期次数限制。refresh token的存储要更谨慎。移动端建议放在系统安全存储区里Web端放在HttpOnly Cookie里减少被脚本读取的可能。服务端收到刷新请求时先校验refresh token签名和有效期再校验设备指纹然后签发一组新的access token和refresh token实现滚动续期。这里有个容易被咬一口的坑客户端时间和服务端时间不可能完全同步直接拿exp和当前时间比较在边界情况下会提前几分钟失效。我的处理方式是校验时加一个“时钟偏移宽容窗口”最常见的是30秒到2分钟取决于业务容忍度now int(time.time()) if now payload[exp] CLOCK_SKEW_ALLOWANCE: return False2.4 服务端Token校验的完整代码一段可用的服务端校验逻辑至少包含四步解码三段、验签、查过期、防重放。def verify_token(token: str) - bool: try: header_seg, payload_seg, signature_seg token.split(.) signing_input f{header_seg}.{payload_seg}.encode() expected_sig hmac.new(SECRET_KEY, signing_input, hashlib.sha256).digest() actual_sig base64url_decode(signature_seg) if not hmac.compare_digest(expected_sig, actual_sig): return False header json.loads(base64url_decode(header_seg)) payload json.loads(base64url_decode(payload_seg)) if header.get(kid) ! CURRENT_KEY_ID: # 密钥已轮换走旧密钥分支 return verify_token_with_old_key(token) if int(time.time()) payload[exp] CLOCK_SKEW_ALLOWANCE: return False # 防重放检查payload里的jti或nonce是否已使用 if redis_client.get(ftoken:{payload[jti]}): return False redis_client.setex(ftoken:{payload[jti]}, 3600, 1) return True except Exception: return Falsehmac.compare_digest这里必须用正常的比较存在时间侧信道虽然本地攻击门槛高但安全代码的习惯还是从一开始就养成。3. 数据加密模块实现3.1 对称加密选型AES-GCM为什么是首选Token解决的是“准入”但body里的实际业务数据还是需要加密。对称加密选型我直接谈结果AES-GCM是首选。为什么不是AES-ECBECB模式相同明文块会产生相同密文块密文中能看出数据模式相当于给分析者递刀子。为什么不是AES-CBCCBC需要padding机制历史上出现过多次padding oracle攻击。为什么不是AES-CTRCTR能保证机密性但不能保证完整性攻击者即使不知道明文也可以对密文做比特翻转让解密结果按预期改变。AES-GCM本质是CTR模式加上GMAC认证标签一个算法同时保机密性和完整性。解密时如果密文被改动了一个比特GMAC标签验证会直接失败这正好配合前面的签名模块形成纵深防御。具体实现用Python的cryptography库import os from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def aes_gcm_encrypt(plaintext: bytes, key: bytes, aad: bytes b) - bytes: nonce os.urandom(12) encryptor Cipher(algorithms.AES(key), modes.GCM(nonce)).encryptor() encryptor.authenticate_additional_data(aad) ciphertext encryptor.update(plaintext) encryptor.finalize() return nonce ciphertext encryptor.tag # 统一拼在一起 def aes_gcm_decrypt(data: bytes, key: bytes, aad: bytes b) - bytes: nonce data[:12] tag data[-16:] ciphertext data[12:-16] decryptor Cipher(algorithms.AES(key), modes.GCM(nonce, tag)).decryptor() decryptor.authenticate_additional_data(aad) return decryptor.update(ciphertext) decryptor.finalize()nonce长度固定12字节tag长度固定16字节。nonce绝不能重复重复使用同一个nonce会导致密钥流复用这是密码学层面的灾难。每次加密都应该重新生成随机nonce不要自己维护递增计数器那在分布式场景下反而容易出问题。3.2 密钥管理与轮换的生命周期密钥管理是多模块加密系统里最容易被低估的部分。我建议每个密钥在配置中心里有这样一组字段字段含义示例值key_id密钥唯一标识用于多版本共存k-2025-001algorithm密钥算法AES-256-GCMcreate_time密钥生成时间2025-01-01 00:00:00effective_time生效时间2025-01-01 00:00:00expire_time过期时间2025-04-01 00:00:00status状态pending/active/retiredactive轮换的关键原则是“新旧共存先立后破”。新密钥生效后旧密钥不能立刻废弃因为存量客户端和缓存数据还在用旧密钥加密。我建议至少保留一个轮换周期让旧密钥处于retired状态只能解密、不能加密等所有旧数据自然过期后再彻底删除。实际项目中我踩过一个坑一次轮换把旧密钥直接标记为失效结果存量客户端请求全部解密失败线上告警一片。后来养成了习惯——凡是涉及密钥生命周期变更先在测试环境用一对真实旧客户端跑一遍兼容性用例再发布。3.3 非对称加密在握手阶段的作用全链路都用AES-GCM的前提是通信双方已经共享同一个对称密钥。但移动端首次启动时不可能把AES密钥硬编码在App里那样逆向一次就全泄露。所以还需要一个握手阶段用非对称加密协商出对称密钥。工程上最常见的做法客户端生成一个临时随机数客户端随机数用服务端公钥加密后发给服务端。服务端用私钥解密用自己的随机数服务端随机数拼上客户端随机数计算出一个会话密钥。后续所有通信都用这个会话密钥做AES-GCM加解密。可以用ECDH协商也可以用RSA-OAEP直接加密会话密钥。具体选哪个不重要只要别用裸RSA就能接受。我的习惯是除非业务需要离线验证否则优先ECDH因为它在同等安全强度下密钥更短、计算更快。3.4 编码的细节Base64URL加密后得到的是一段二进制密文不能直接放进URL参数或JSON字段里。标准Base64包含、/、三个字符放在URL里会需要转义放在某些JSON解析器里也可能踩到不兼容。因此统一用Base64URL编码。规则很简单替换成-/替换成_去掉末尾的填充。解码时再补回来。前面的Token生成代码里已经用了这套逻辑加密后的密文也建议统一走同一套编解码函数避免一个系统两套Base64函数互相打架。4. Gzip压缩技术与加密的配合4.1 先压缩还是先加密顺序问题这个问题我在一次技术评审里跟人争过对方认为压缩和加密都是对数据做变换先后顺序无所谓。但这里顺序是硬性的必须先压缩再加密。原因是两类算法的数学基础不同。压缩的本质是消除冗余寻找数据里的统计规律加密的本质是把数据变成高熵随机串消除可读规律。如果先加密明文已经变成完全无规律的字节流任何压缩算法面对高熵数据都无能为力甚至因为格式头反而体积变大。反过来先压缩再加密压缩后的数据体积已经变小加密不改变体积传输总量自然最优。这个问题的另一个变体是“签名和压缩谁先谁后”一般建议先压缩后签名因为签名是对最终传输内容的约束。如果先签名再压缩服务端验签时得先解压才能看到原始签名逻辑绕一圈还不利于流式处理。保持“压缩 → 签名 → 加密”的管线顺序是最顺的。4.2 压缩参数调优与阈值设计Python标准库提供了gzip.compress和gzip.decompress压缩级别从0到9默认6。对JSON文本这类高冗余数据压缩级别6到9的压缩率差异不大但CPU耗时差异明显我建议保持6就行。更关键的是压缩阈值的设计。Gzip数据流自带几十字节的头尾开销如果业务数据本身只有几十字节压缩后反而变大。我在项目里做过一次全量埋点统计结果如下原始数据大小压缩后大小是否值得压缩24字节46字节否变大了128字节79字节勉强收益低1KB307字节是明显收益48KB9.1KB是收益极大所以我客户端和服务端的压缩模块都加了一个判断原始数据小于256字节就不压缩直接走明文分支。这个阈值不是拍脑袋定的是根据线上分布测出来的。不同系统数据特征不同建议你也做一次采样统计再定。4.3 防重放载荷的设计加密和压缩解决了机密性和体积但还缺一环防止攻击者录制一个合法请求后反复重放。所以我在压缩前先拼装一个这样的结构{ timestamp: 1740130656, nonce: f47ac10b-58cc-4372-a567-0e02b2c3d479, data: { ... 业务数据 ... } }服务端解密后按三步校验timestamp和当前时间差是否在允许窗口内比如5分钟。nonce是否在缓存字典里出现过出现过则拒绝。校验通过后把这个nonce写入本地缓存的去重集合设置过期时间等于防重放窗口。这里有个性能取舍如果请求量巨大每个请求都存nonce可能会撑爆Redis。我的做法是只在涉及敏感操作改密码、下单支付的接口启用防重放普通读接口不做节省存储和延迟。5. 完整链路串起来跑一遍5.1 客户端请求生成的完整流程把前面几个模块串起来客户端生成一个请求的完整步骤是构造业务数据对象比如一个查询商品列表的请求参数。取当前时间戳生成随机nonce。组装防重放载荷{timestamp: ..., nonce: ..., data: ...}。对序列化后的JSON做Gzip压缩。用AES密钥对压缩后的字节做GCM加密得到nonceciphertexttag的二进制。做Base64URL编码放进请求body字段。在header里带上之前获取的access token。完整代码示例def build_secure_request(payload: dict, aes_key: bytes, token: str) - dict: body { timestamp: int(time.time()), nonce: uuid.uuid4().hex, data: payload, } plaintext json.dumps(body, separators(,, :)).encode() # 1. 压缩 if len(plaintext) 256: compressed gzip.compress(plaintext, compresslevel6) else: compressed plaintext # 2. 加密 encrypted aes_gcm_encrypt(compressed, aes_key) # 3. Base64URL return { body: base64url_encode(encrypted), token: token, }5.2 服务端验收到响应返回的完整流程服务端接收后是一条逆向链路从header提取token并执行校验。取body里的Base64URL字符串解码成二进制。解析密文头部的key_id找到对应的AES密钥。用AES-GCM解密得到压缩字节流或未压缩的明文。根据压缩标记判断是否需要解压。解析JSON校验timestamp和nonce。校验通过后才把业务数据交给上层逻辑。def parse_secure_request(data: dict, verify_token_func) - dict: # 1. 校验token if not verify_token_func(data[token]): raise PermissionError(invalid token) # 2. 解Base64URL encrypted base64url_decode(data[body]) # 3. 从header里提取key_id选择密钥 header parse_inner_header(encrypted) aes_key get_key_by_id(header[kid]).value # 4. 解密 decrypted aes_gcm_decrypt(encrypted[header_end:], aes_key) # 5. 按标记判断是否压缩过 if header[compressed]: decrypted gzip.decompress(decrypted) # 6. 解析并校验防重放字段 payload json.loads(decrypted) if abs(time.time() - payload[timestamp]) 300: raise InvalidRequest(timestamp expired) if not nonce_cache.check_and_set(payload[nonce], ttl300): raise InvalidRequest(nonce reused) return payload[data]响应走同样一套流程区别是压缩标记和服务端返回码可以简化一点。5.3 性能实测与长度变化我在本地用一份典型商品列表JSON做了测试数据特征如下指标数值原始JSON大小48KBGzip压缩后9.1KBAES-GCM加密后9.1KB 28字节头Base64URL编码后约12.3KB整体耗时压缩加密约25ms压缩带来的体积收益非常明显从48KB降到9.1KB节省了约80%的传输量。而加密步骤本身几乎不影响体积多出来的只是nonce和tag。如果你在压测时发现加密后体积出现明显膨胀往往是数据本来就是高熵的比如已经加密过这种情况不要硬优化。6. 常见问题与排查技巧实录6.1 Token校验失败但未过期这类问题在线上出现频率最高原因通常有三个客户端时间和服务端时间偏差太大服务端校验时加上宽容窗口仍然超过exp。排查时先看客户端设备时间和服务端时间差真的差太多应该引导客户校准时间而不是无限加大窗口。密钥轮换后客户端还在用旧密钥签名。这是最常见的原因服务端需要保留旧密钥一定时间且校验逻辑里要按kid分发到对应密钥而不是只有一个当前密钥。签名算法不一致。比如header声明HS256但实际用HS512去算签名校验时也按声明算法做两边对不上。排查时可以先生成一组已知token做单元测试。6.2 压缩后体积反而增大如果你发现压缩后体积增大先别急着怀疑压缩算法。Gzip对文本类数据压缩效果极好对已经加密的二进制、图片、视频数据基本无效。另外请求体过小时Gzip头部和尾部开销会抵消压缩收益。此时应该检查压缩阈值配置而不是改算法。我在一个项目里就遇到过业务同学把所有POST body都先做了一次“统一加密”到我这层再压缩结果gzip根本压不动。排查到最后发现是上游先加密了顺序错了和我们的Gzip模块无关。后来我在架构文档里明确写了压缩和加密的顺序约束还加了一个配置项对检测到的高熵数据直接跳过压缩。6.3 跨语言解密失败的典型坑服务端和移动端如果用的语言不同最容易出问题的不是密码学本身而是编码和拼接细节nonce、ciphertext、tag三段拼接顺序不一致。有的库返回格式是nonce ciphertext tag有的是ciphertext tag分开管理。解密前必须确认双方约定。Base64URL和标准Base64混用。尤其是Java的Base64.getUrlEncoder()和Python的urlsafe_b64encode一个带padding一个不带混用直接报错。建议统一封装编解码层禁止到处直接调库。AES密钥长度不匹配。有人用32字节的key声明AES-256实际传过去的只有16字节Java和Go的默认行为不同这类错误排查起来最隐蔽。排查方法也很简单用固定的测试向量明文固定、密钥固定、nonce固定分别用两端生成密文逐字节对比。只要你能用固定向量把两端拉通剩下99%的问题都出在业务代码而不是算法库。6.4 排查工具与定位思路遇到加解密相关的问题先用工具把阶段边界切开。我常用的三板斧抓包工具确认线上请求和响应里的密文片段是否完整比如tag是否被截断、Base64URL是否被转义。openssl命令行可以手动解密一段样本排除业务代码干扰。例如用openssl enc -d -aes-256-gcm配合固定密钥nonce验证明文。本地复现脚本用一个Python或Java脚本把线上抓到的密文、密钥、nonce、tag固定住跑一次解密看是哪里报错。定位思路永远是先确认数据有没有被截断或篡改再确认算法参数是否一致最后才怀疑密钥和算法本身。我调试跨端加密问题最多只花半小时靠的就是这个顺序。最后分享一点个人体会。做这种加密系统出问题的极少是算法数学层面绝大多数是版本兼容和模块边界。我印象最深的一次返工是把token刷新和加解密逻辑耦合在一起结果改一个默认有效期顺手改了AES密钥轮换逻辑上线后高版本客户端全部解密失败。从那以后我再不敢把模块边界糊在一起每一层的数据格式都用版本号显式标记。如果你也要做类似的东西我建议从最开始就把模块拆干净每一个字段都带上kid、ver这样的版本标识不要等回头再补。这套多模块加密系统在我这边已经稳定跑了两个大版本期间没再出过全网事故。