投放系统中如何防止恶意请求（如刷量），比如限流、验证码、IP黑名单，或者数据传输中的加密（HTTPS），请举例说明具体实现方案。
360Web服务端开发工程师-投放方向难度：中等
答案
1) 【一句话结论】投放系统防恶意请求需多维度策略组合（限流、验证码、IP黑名单、HTTPS），通过识别异常行为模式，动态调整阻断或降级策略，核心是平衡业务可用性与安全性，同时考虑分布式环境下的可扩展性。
2) 【原理/概念讲解】老师讲解：
- 限流：控制请求速率的机制，通过令牌桶算法，维护一个令牌池，每秒生成固定数量的令牌，请求时消耗令牌，若令牌不足则拒绝。类比：交通红绿灯，控制车流量，避免服务器过载。
- 验证码：通过用户交互（如短信、滑动验证）验证身份，防止自动化工具。原理是增加人工操作步骤，区分机器与人类。类比：身份证核验，需人亲自操作，避免机器模拟。
- IP黑名单：静态阻断已知恶意IP。原理是维护黑名单列表，请求时检查IP是否在列表中，若在则直接拒绝。类比：黑名单电话，打不通或被拦截，快速阻止已知攻击源。
- HTTPS：加密数据传输，防止中间人窃取或篡改。原理是使用TLS/SSL协议，客户端与服务器建立加密通道，确保数据在传输过程中不被窃取或篡改。类比：加密信封，内容只有收发双方能看，保护敏感信息（如投放参数、用户标识）。
3) 【对比与适用场景】
| 策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 限流 | 控制请求速率的机制，通过令牌桶算法动态限制单位时间内的请求次数 | 动态调整，支持突发流量，可配置阈值 | 高并发场景（如360投放系统中的秒级投放请求集中），防止服务崩溃 | 阈值需根据业务流量动态调整（如冷启动时降低阈值，突发流量时提高阈值），避免误判正常用户 |
| 验证码 | 通过用户交互（如短信、滑动验证）验证身份的技术 | 需用户手动操作，增加请求延迟 | 防自动化刷量（如频繁投放请求），需要用户交互的场景（如新用户首次投放、高价值投放操作） | 用户体验与安全性的平衡，复杂验证码（如图片验证码）可能影响转化率，可采用滑动验证码（更友好） |
| IP黑名单 | 静态阻断已知恶意IP的列表 | 硬性阻断，无延迟 | 已知的恶意攻击源（如频繁请求的IP，通过日志分析识别），快速拦截恶意请求 | 需定期更新黑名单（如与安全团队联动，分析异常日志），避免误判正常用户（如新IP误入黑名单），可设置白名单（如正常业务IP） |
| HTTPS | 加密数据传输的协议，使用TLS/SSL | 传输层加密，防止窃听/篡改 | 敏感数据传输（如投放参数、用户信息），保护数据安全 | 部署成本（证书获取、配置），需确保服务器证书有效（如定期检查过期时间），配置HSTS强制使用HTTPS，防止中间人攻击 |
4) 【示例】：以分布式限流（Redis令牌桶）为例，说明在360投放系统中的实现：
假设投放请求的API为/api/delivery，使用Redis存储令牌桶状态。
- Redis令牌桶配置：
- 令牌桶容量（capacity）：100（每秒允许的请求数）
- 令牌生成速率（rate）：100（每秒生成100个令牌）
- 令牌桶键：
rate_limit:delivery:ip:{client_ip}（按IP隔离，避免跨用户限流）
- 伪代码（Redis操作）：
请求示例：用户发送POST请求到import redis r = redis.Redis(host='localhost', port=6379, db=0) def is_allowed(ip, request_rate=100, capacity=100): # 获取当前令牌数，若不存在则初始化为容量 tokens = r.get(f'rate_limit:delivery:ip:{ip}') if tokens is None: tokens = capacity r.setex(f'rate_limit:delivery:ip:{ip}', 1, tokens) # 1秒后过期 else: tokens = int(tokens) if tokens > 0: r.decr(f'rate_limit:delivery:ip:{ip}') return True else: # 令牌不足，等待时间流逝 wait_time = 1 / request_rate r.setex(f'rate_limit:delivery:ip:{ip}', wait_time, tokens) return False def handle_delivery_request(request): client_ip = request.headers.get('X-Forwarded-For', request.client_ip) if not is_allowed(client_ip): return {"code": 429, "msg": "请求过于频繁，请稍后再试"} # 处理正常投放逻辑 # 例如：验证投放参数（如金额、目标URL），记录投放日志 process_delivery(request) return {"code": 200, "msg": "投放成功"}/api/delivery，携带参数（如amount=100，target_url=...），服务器首先调用is_allowed()检查令牌，若返回False则返回429错误；若通过则处理投放逻辑（如调用广告投放接口，记录日志）。
5) 【面试口播版答案】（约90秒）：
“面试官您好，针对投放系统防恶意请求，我会从多维度策略说明：首先，限流是核心手段，通过分布式Redis令牌桶算法控制请求速率，比如360投放系统中，每秒为每个IP允许100次请求，超过则返回429错误；其次，验证码用于高并发场景，比如新用户首次投放时，通过短信验证码或滑动验证，用户输入验证码后才能投放，防止自动化工具刷量；然后，IP黑名单用于阻断已知恶意IP，比如维护黑名单数据库，请求时检查IP是否在列表中，若在则直接拒绝；另外，HTTPS用于数据传输加密，确保投放参数（如金额、目标URL）在传输过程中不被窃取或篡改。这些策略结合使用，能从速率、身份、来源、传输多个层面防御恶意请求，同时考虑分布式环境下的可扩展性，避免单点故障。”
6) 【追问清单】及回答要点：
- 问：分布式限流中，如何处理冷启动（系统刚上线时，流量未知，阈值设置不合理）？
回答要点：冷启动时降低限流阈值（如初始为50次/秒），随着流量数据积累，动态调整阈值（如基于历史流量统计，逐步提高阈值），避免正常用户被误限流。 - 问：验证码的动态触发逻辑，如何避免影响正常用户？
回答要点：根据用户行为动态触发，比如连续多次（如3次）投放请求失败或异常参数（如金额异常），才触发验证码；对于正常用户（如高频次但参数正常的用户），不触发验证码，减少操作成本。 - 问：IP黑名单的误判处理，如何避免新IP正常用户被阻断？
回答要点：设置白名单（如正常业务IP，如公司内部测试IP、合法广告主IP），同时采用误判恢复机制（如若IP被误判后，若后续请求行为正常，移出黑名单），并定期人工审核黑名单。 - 问：HTTPS部署中，如何处理证书过期或中间人攻击？
回答要点：配置自动证书续期（如使用Let's Encrypt的自动续期工具），定期检查证书有效期；配置HSTS（HTTP Strict Transport Security）头，强制客户端使用HTTPS，防止中间人篡改请求参数。 - 问：不同策略的优先级，比如限流和验证码同时触发时如何处理？
回答要点：按业务逻辑顺序，先限流（快速响应，避免资源耗尽），若限流通过再验证验证码（防止自动化工具），若验证码失败再检查IP黑名单（阻断已知恶意IP），最后检查HTTPS（传输安全），确保安全层层递进，用户体验和安全性平衡。
7) 【常见坑/雷区】：
- 限流阈值设置不合理：阈值过低导致正常用户请求被频繁拒绝（如正常用户每秒发送2次请求，阈值设为1次，影响投放体验）；或阈值过高无法阻止恶意请求（如恶意用户每秒发送1000次请求，阈值设为1000次，无法限流）。
- 验证码滥用：复杂验证码（如图片验证码）增加用户操作成本，导致用户流失；或验证码被破解（如图片验证码被OCR工具识别，导致验证码失效）。
- IP黑名单更新不及时：无法拦截新恶意IP（如恶意用户使用新IP发起攻击），或误判正常用户（如新IP属于合法广告主，被加入黑名单，导致正常投放失败）。
- HTTPS只关注传输，忽略业务逻辑：即使传输加密，若业务逻辑存在漏洞（如参数可被篡改，恶意用户修改投放参数），仍可能被攻击。
- 策略组合不协调：限流和验证码同时触发，导致用户多次操作失败（如限流后返回429，验证码失败后再次返回错误），引发用户投诉，影响业务转化率。