加随机串
换个思路，我们在请求报文里面加个随机串，然后让它参与加签。
接受方收到报文，验签之后，把随机串拿出来，来判断一下这个随机串是否已经处理过了。比如判断一下是否存在于 Redis 里面。
当请求再次重放过来的时候，一看：嚯，好家伙，这个随机串已经被用过了呀，不处理了。
在这个情况下，随机串就得保证唯一性了，还得历史全局唯一。
因为你指不定哪天就收到一个几天前的被重放过来的请求。
确实是解决了请求重放的问题，但是弊端也很明显：历史全局唯一。
我还得存储下来，而且存储的数据量还会越来越大，是不是有点麻烦了？
确实麻烦了。
这个思想就和用全局唯一流水号去保证接口幂等性很像了。
所以，我第一次遇到这个面试题的时候，我朝着接口幂等的角度去回答了，也不能说回答的不对。
只能说回答的不是面试官想要的标准答案。
那么什么是面试官想要听到的回答呢？
时间戳+随机串
时间戳的问题是有一定的时间容错窗口，这个时间窗口内的重放攻击是防不住的。
随机串的问题是要保证历史全局唯一，保存随机串成了一个麻烦的事情。
那么当我们把这两个方案揉在一起的时候，神奇的事情就发生了：
我只需要保证时间窗口内的生成的随机串不重复就行。
而且假设时间窗口为 60 秒，我们用 Redis 来记录出现过的随机串，那么这个串在后台的超时时间设置为 60 秒就行。
一般来说这个时间窗口都不会太长了，我对接过这么多各种各样的渠道，见过最长的也就 5 分钟。
保证 5 分钟内生成的两个随机串不重复，这个需求比保证实现一个历史全局唯一的流水号容易实现多了吧？
另外，最关键的一句话一定要说：时间戳和随机串得参与到加签逻辑中去。
这个很好理解吧？
接受方看报文是否被篡改，看的就是签名是否能匹配上。
而签名的结果是和参与签名的字段的值有直接关系的。
要是你时间戳和随机串不参与加签，那么任意修改时间戳或者随机串，都不会引起签名的变化，那不白忙活一场吗？
中间人咔一下拦截到请求，发现有时间戳和随机串，正准备放弃的时候，想着死马当做活马医，把随机串一改，又扔给接收方了。
结果收到正确的响应了。
我要是这个中间人，我都会笑出来声来：写这个代码的程序员也太可爱了吧？
微信支付
其实说到时间戳加随机串的时候，我就想起了微信支付。
刚刚入行的时候，可是被这个微信支付搞的服服帖帖的。
但是需要说明的是，虽然它的接口文档里面也有时间戳加随机串，但是目的不是为了防止重放攻击的。
写出来呢只是为了让对于加签这个东西不太熟悉的朋友有一个具体的认知。
来，我们看一下微信支付的接口文档：
https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=7_7&index=6
可以看到请求参数里面确实有时间戳（timeStamp）和随机字符串（nonceStr），且人家还专门加粗了：
参与签名的参数为：appId、timeStamp、nonceStr、package、signType，参数区分大小写。
那么是怎么签名的呢？
官方也是给了详尽的说明的：
https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=4_3
首先就是按照字典序，对所有需要参与签名的、非空的字段进行排序。并使用 URL 键值对的格式（即key1=value1&key2=value2…）拼接成字符串 stringA。
然后在 stringA 最后拼接上 key（商户密钥） 得到 stringSignTemp 字符串，并对 stringSignTemp 进行 MD5 运算，再将得到的字符串所有字符转换为大写，得到 sign 值 signValue。
官方给了一个实际的案例，如下：
再说一次：微信支付的接口里面虽然有时间戳加随机串，但是目的不是为了防止重放攻击的。写在这里只是让大家对于加签这个过程有一个具体的认知。
别整茬了。
那么它在接口里面加入随机串的目的是什么呢？
官方自己都说了：
微信支付API接口协议中包含字段nonce_str，主要保证签名不可预测。我们推荐生成随机数算法如下：调用随机数函数生成，将得到的值转换为字符串。
阿里API网关
看完微信支付，再看看阿里的 API 网关是怎么防止重放攻击的。
