这种多了去了, 我们系统有超过 1% 的流量是这种漏洞探测的. 还是被 WAF 过滤掉一部分之后的.

@Yjhenan 这个有点秀

@thinkm 细说?
@debuggerx 如果能 toInt 干嘛不直接 int

traceroute 看下 hope, 基本能根据路由线路判断出来

@thinkm 细说?

@debuggerx 就是因为 protobuf 用了 fixnum 才难受, go_router typedroute 都不支持 int64 作为参数

我想了解的是俩问题: 一个是 ikuai 本身从数据层面讲靠谱不, 另一方面是, ikuai 这个出海流量, 算是灰色产品么?

直接买 ikuai 的路由器呢? 如果 ikuai 合规的话, 我们考虑直接买. 比如这个: https://item.jd.com/100004090261.html

@mm2x 想再问一下: ikuai 这个靠谱么? 我们代电信的, 他们的设备也要我们用 ikuai 的路由器. 我网上扒了一下, 说是 ikuai 有后门.

感谢各位大佬

你附加里面的其实是两个问题: 一个是如何避免前端伪造证明自己看过广告领奖的接口调用, 另一个是如何证明广告是真被看过的.

前面一个其实不难, 滑块验证码这类的技术方案很成熟. 但是后面一个不太常见, 类似于要自己实现一个滑块验证码. 主要是要把看广告的过程转化为特征值供校验. 我感觉业界应该是有解决方案的, 比如那些在线视频学习网站, 要求必须看完整个视频才能完成课时.

有个解决方案是: 基于隐藏式的滑块验证码技术收集前端特征, 保证前端环境是可信的, 然后视频每看一秒, 就对看过的内容进行一次签名, 得到两个签名一起提交的服务器. 服务器做校验.

统一回复一下: 我并没有在面试过程中问过一次这样的问题, 而是在沟通过程中发现相当一部分人在描述自己的项目的时候对是这么用上游/下游这两个词的.

这么描述是有歧义的, 因为在相当多的场景下, 这个概念是不能调换的, 比如我依赖一个第三方云服务, 或者做链路跟踪的时候, 上游一定是被依赖方. 如果这个时候对语义的理解无法达成一致, 沟通起来是有问题的.

@54qyc 这种说法的结果是: 如果我是个前端, 用相同的语义来表达的话, 我调的后端成了下游服务, 前端反而成了后端的上游.

@merryMa 你说的这个叫下层, 上层服务依赖下层, 但是上下游是把过来的, 指的是数据流向, 或者依赖方向, 被依赖的是上游.

@corcre 所以你们有用啥 VPN 软件么? 我理解这个是必需的?

@corcre 厉害

@brsyrockss 不赚, 还在扩大规模阶段.

@corcre 你们内网是用的啥 vpn 啊? 深信服说是不支持 aws, 我们机器在 aws 上. 剩下的就得选 cisco 了?