我现在做API网关项目的时候，遇到过重放攻击。 这是比较常见的攻击。 什么是重放攻击？
百度百科
重放攻击(Replay Attacks )，也称为重放攻击，是攻击者发送目标主机接收到的数据包，以达到欺骗系统的目的，主要用于认证过程，破坏了认证的准确性。 重放攻击既可以由发起方进行，也可以由截获该数据并重新发送的敌人进行。 攻击者利用网络监听等窃取认证证书，并将其重新发送到认证服务器。 任何网络路径都可能发生重放攻击，是计算机全球黑客常用的攻击方法之一。
针对重放攻击，主要有以下防护方式
百度百科
(1)将随机数相加。 这种方法的优点是不需要时间同步来认证双方，而双方都记得所使用的随机数，并且一旦发现消息中有以前使用的随机数，就被认为是重放攻击。 缺点是需要额外保存使用过的随机数，记录时间长会增加保存和查询的开销。
)2)加时间戳。 这个方法的优点是不需要保存其他信息。 缺点是认证双方需要准确的时间同步，同步越好，受到攻击的可能性就越低。 但是，当系统庞大、跨越广泛时，要实现准确的时间同步并不容易。
)3)打上流水符号。 双方在消息中添加逐步增加的整数，如果接收到不连续的流消息(过大或过小)，则认定存在再生威胁。 这种方法的优点是不需要时间同步，保存的信息量比随机数方式小。 其缺点是攻击者成功解密消息后，可以获取流号码，每次都向认证方逐步欺骗流号码。
这几种防护方式如果单独使用，都有各自不同的缺点，如何做好重放攻击的准备呢？ 时间戳方式。
时间戳的处理
时间戳的应用存在以下问题，需要优化
客户端和服务器端的时间可能不同步，时间差可能很大。 因此，客户端和服务器之间的时间差限制不能太小，例如10分钟
只能用时间戳防护，不能播放阈值范围内的请求
为了解决时间戳中客户端和服务器端时间不同步的问题，采用了**相对时间**。
设客户端时间为t1，服务器端时间为t2。 客户端首次启动时，缺省相对时间T=0。
客户端开始请求t1 T作为时间戳
如果时间差太大，服务器端拒绝了请求，则将当前的服务器端时间t2 (可以使用标准时间)返回给客户端
客户端将更新相对时间T=t2-t1，并在本地缓存时间以供下次启动时使用。 返回步骤2
相对时间可以保证，无论是服务器端时间异常，客户端时间异常，还是时区本身的时间不一致，发起请求时发送的时间戳都不会相差很大，通常不会超过1秒。 如果超过1秒，则会影响客户端性能，要求本身必须进行优化
随机数的处理
随机数的生成方式有几种，无论如何服务器都需要识别该随机数是否出现。 请求本身需要防止参数被篡改，签名也基本上保证了随机性，所以直接使用了签名作为随机数。
最大的问题是如何保存随机数。 保存时间越长，对服务器端的压力就越大。 优化时间戳后，为了保险起见，假设时间差超过10秒时拒绝请求，保存10秒的随机数就可以防止重播攻击。
可以根据访问次数选择不同的计划。
如果访问很低(如1000QPS或更低)，则保存10000个或更少的随机数可以通过独立服务器的本地缓存解决。 分布式服务也可以通过redis等缓存来解决。
100万QPS等访问量较多时，需要保存1000万个随机数。 我该怎么办？ 使用MD5签名得到的随机数为长32位，即32字节、1000万的随机数，需要3亿1000万字节。 需要约300MB以上的空间。 这是很大的空间。 1000万QPS的话，需要3G以上。 ***布隆过滤器****可以解决这个问题。 布隆过滤器不用介绍，自己就可以查了。 布隆过滤器主要需要注意误算率。 (redis正好提供bitmap实现了。
要用布隆过滤器保存签名，需要将十六进制转换为数字，并使用BigInteger防止越界。 为了降低误算率，可以根据签名计算多个不同的数字。 我们使用的签名和签名是按相反顺序计算的两个数字。 这两个数字是布隆过滤器的两位数。
private long [ ] get offsets (string sign ) BigInteger使用较大的数字bigintegerpositivenum=newbiginteger (sign，16 )； bigintegerreversenum=newbiginteger (new stringbuilder (sign ).reverse ) ).toString )，16 )； Long[] offsets=newLong[2]； offsets [0]=positivenum.mod (big integer.value of (integer.max _ value/2 ) ).longValue )； offsets [1]=reverse num.mod (big integer.value of ) integer.max_value/2 ) ).longValue )； 返回偏移； }使用更大的bitmap还可以降低误算率，例如使用10亿位的bitmap保存1000万的随机数。 但是，10亿位的bitmap操作存在以下问题。
1 .初始化太慢
2 .读写数据缓慢
有以下几点改进措施：
请求包含timestamp和随机数，可以根据不同的时间将随机数路由到不同的bitmap，例如10ms或50ms。 解决了bitmap过大导致初始化速度慢的问题，也可以降低误算率，可以将不同的参数组合起来路由到不同的bitmap以区分不同的api，不需要防止重放攻击的接口，计算