最近在看点评网站：
感觉里面防爬做的蛮好：验证方面采用随机验证类型（滑块、极验、连连看等等还有其他）；而且网页间的上下层级关联性做的特别好，如果绕过上一页直接访问下一页数据，就会跳转到验证页面，认为此操作不是一个正常人的访问行为；再者里面采用Ajax动态加载居多。
然而，我感觉最巧妙的一点应该上图红框框圈出来的那个防爬操作，点评返回的脚本中包含资源请求：http://114.80.165.63/broker-service/api/single?tu=midas-cpm&ts=1580718662601&hs=2002&d=807，页面渲染并请求这个网址时，服务器端会hold住请求不返回，一直到浏览器超时自动断开为止。
如果我们想通过http请求直接去获取点评数据的话，难度比较高，简单一点可以用动态引擎去渲染完毕后再返回。动态引擎特性是会等到页面的数据全部加装完毕再返回，再结合上面114.80.165.63资源会hold住请求不响应，这样就会导致动态渲染引擎直到超时才会返回数据。
说上面的请求防爬比较巧妙主要有两点：
- 用ip而不是域名：如果用域名的话，我们可以直接在hosts讲域名映射到127.0.0.1这样就能直接返回；
- hold住请求不返回：让请求方等到死为止，然而由于这个请求不返回任何有效资源，因此还不影响浏览器端用户的正常操作~
愁人、、、
我们的动态引擎部署在K8S中
Calico用法
我这边用的k8s用的网络组件是flannel还不方便操作规则，然后就换成了calico，配置了egress规则进去：
- apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: deny-egress-ips
spec:
selector: "all()"
types:
- Ingress
- Egress
ingress:
- action: Allow
egress:
- action: Deny
destination:
nets:
- 114.80.165.63/32
- action: Allow
达到了deny的效果，但是没有明确拒绝导致不能实时返回。
Iptables规则
直接在node节点的iptables追加了一条：
iptables -A OUTPUT -p tcp -d 114.80.165.63 --dport 80 -j REJECT
在节点上面curl网址效果明显，但是仍然需要2s才能返回，因为默认情况--reject-with是icmp-port-unreachable，这个发起两次syn操作。对比了下换成了tcp-reset，只会发起一次syn，返回时间在几十ms。
配置完毕后发现对节点上面发出的请求有效，对pod发出的请求无效，分析了下原因：k8s流转的数据包都mark了特殊标识，会走特定的chains，因此将规则添加到了KUBE-SERVICES chains中即可。
iptables -A KUBE-SERVICES -p tcp -d 114.80.165.63 --dport 80 -j REJECT --reject-with tcp-reset
批量操作：
for l in `cat node_ips`; do ssh $l 'iptables -A KUBE-SERVICES -p tcp -d 114.80.165.63 --dport 80 -j REJECT --reject-with tcp-reset'; done
