@pursuer 因为发在 py 专区，py 似乎是没有标准库实现，要跨进程调用的话似乎就不那么优雅了

@renmu123 不太容易实现，打开 A 页面的同时需要根据鉴定是否为爬虫，决定是否返回正确信息，此时 js 脚本刚刚加载。想实现只能保留 B 页面执行的结果，并让这个结果不随页面刷新改动，可能整个网站都要用 ajax 异步加载的方式才能做，成本太高了。

@jim9606 简单查了一下 pow，感觉是个挺有意思的机制。不过似乎不太好实现，一个简单的方法是后端找一个随机数，生成 hash，告诉前端 hash 的结果和随机数大概的生成范围，让前端用穷举法算出原始数值。这种实现有两个问题，一个是前端算力不同，不同用户访问同一个网页可能有的人 0.5 秒就算完了，有的人 5 秒钟也算不完，比较影响体验。

再一个是这种没法在单次连接里验证，需要发起两次连接。后端需要处理多连接状态同步的问题，其实也提高了后端成本，感觉不是很划算。不过应该是确实能有效提高爬虫成本，是一个有意思的思路

@opengps
@ClericPy 理论上确实是想实现“让别人发现我正在提供服务”这个功能。比如设计一个简单的使用场景，在一个多进程基于 tcp 的通信中，我现在有一个固定的中心服务器，比如绑定到 center.service.com:443，我想实现的效果是每个服务器，即使在不同的机器中，只需要运行 server = center.connect()就可以告知目前在线的所有人连接我这个服务的方式。

理论上几种做法，一种是由于大家都和 center 有连接，所有流量都经由 center 代理，这种在多节点通信情况下效率太低，不作考虑。另一种是由服务端上线时自己设定好，比如 server = center.connect(my_ip='192.168.0.100')，然后绑定服务到这个 IP，这个感觉又太麻烦了，理想的情况下就是 server 不用进行任何设置直接启动，然后自动绑定 0.0.0.0 的某个端口，并且自动获取到其他人访问哪个 IP 可以经由 0.0.0.0 转接。

可能说的不太清楚，需求比较怪，两位见谅。

@ysmood 学到了一个好用的反爬方法，感谢

爬虫爬的好，牢饭吃到饱。没什么意义，现在框架写出的网站都是前端渲染前端路由，不跑无头你能拿到什么数据。然而只要跑无头基本就获得与正常用户一样的使用体验，所以比起爬虫我倒是更关心如何反爬。。

@matrix67 因为 python 本身慢，再加上没有 switchcase，这种逻辑比原生可能慢个几百倍。有重复运算的部分很容易瓶颈，确实需要找优化方案

@matrix67 他是 python，所以实际不是表驱动，更像是 mapdriven，哪个快不好说，大概率更慢

@Aliencn
@wanguorui123 感谢，看了一下资料，总结来说问题确实存在，而 TCP 也确实有 hash 校验选项，只不过默认不开启。Linux 内核提供了 tcp md5 的功能，但手册语焉不详，需要传入指定内存结构的结构体，导致类似 java 之类的语言里启用传输层的校验似乎比较困难。

解决方案的话，本身下层还有校验，我本人提问的时候也不觉得这是个高发情况，所以非关键业务可以忽略。特殊业务场景，可信网域的话可能有特殊需求，比如 tls 成本太高的话可以应用层自己实现，使用一些快速哈希之类的。

@bugmakerxs 硬件实现原子操作的指令一样而已，我不理解你所谓的本质一样是什么意思。有的锁需要切换内核态，与不需要切换的锁，本质相同吗？我不觉得

@volvo007 显然套函数需要先定义，再调用，写两行代码多于原先一行代码，这是其一。同时函数引入新的 scope，单独测试段落引起上下文定义缺失问题，这是其二，以上两点是否很难理解？

看了这么多帖子下来，房子这事其实无所谓，因为有升值潜力，女方又愿意出钱，没什么成本差别。

可能问题比较大的是要不要孩子吧，认真谈一谈，真的不要的话只能分手。我跟前女友分手的重要原因是在要孩子问题上不和，而且是很认真的谈了之后无法说服对方，可能也是后面分手的重要原因之一吧

你这个网页搞得太土，甚至让我迷之感觉到人家两百万花的不亏。

你这个字体，还有圆角弧度之类的，一点设计感都没有，调着调着瞅了一眼左上角，一对比差远了

@xiaolinjia 测了一下确实，我的阈值大概长度 25 左右时速度相等。

理论上 np 的主要开销在于 ffi，不同的优化程度 ffi 调用开销在几十到几百纳秒不等。C 语言进行这么短的计算的开销可以认为不存在，cache 不会 miss，大概几个 clock 之内搞定，可能个位数纳秒，或者 1 纳秒。

原生的话，主要在于新建和回收列表的开销，因为这部分已经高度优化了，cache 不 miss 的情况下可能几十纳秒，循环过程的开销也比较高，可能几十纳秒，加在一起得到一个合计的阈值。不过可以看出来 py 追求性能还是颇拉胯的，随着列表长度增长会有明显的开销增长，c 的话可能你长度为 1 和长度为 1000 感受不到什么区别。

@liprais
@charexcalibur

装饰器方案比现在更拉胯，比如我有一个简单的需求，我有某个列表，需要把里面内容全部+2，完全用原生实现我要考虑是循环速度快还是列表生成器速度快，像下面这两段代码

https://gist.github.com/GoodManWEN/23274b3bcdd6fbeb352bea9f44b85441

我用现在的方案，实现循环我需要多写一行 for _ in range(1e8):，如果用装饰器，还要多定义一个函数，并且引入一个新的 scope，语法没有变简洁，问题变多。

@xiaolinjia
https://gist.github.com/GoodManWEN/dc9372c7a0288837aa4ffd4b0ddc85f8

明显你测试有问题，我测试里长度为 100k 情况下 np 比原生快 200 倍，长度为 1k 下快 55 倍

@dapang1221 1kw 慢明显是没优化，不用嘲讽楼主了。。不过话说回来 mysql 确实跟同类产品比性能不行啊，pg 和 oracle 大概 1kw 数据没优化硬顶也能顶住吧