最好架一个 wordpress 什么的。
根据校长最近的 paper 墙会辅以“主动验证”的手段来做“主机行为识别”。

未验证，供参考。

我靠，这贴歪得有水平。各种吐槽啊。。。

楼主同学，想做一件事，那就去做，别想那么多，因为并不需要想那么多。

神马吃饭糊口，养妻活儿，光宗耀祖，买房养车，把全世界的期望值都压在这一件事情上，放眼望去，哪份工作经得住这么一压的？换句话说，你在找的不是一份工作，而是成功，和生存的焦虑。

不要陷进“窄巷思维”，纠结的事情和你想要的结果之间，存在必然的逻辑关系么？

30 岁开始学编程，和以编程为求生技能之间是存在鸿沟的。谁说你不可以一边干你能养活自己的工作，一边自学编程的呢？等你的水平足够找一份挣钱更多的程序员工作了，这个纠结才会成为问题（兄弟，这个目标不容易达成呢）。在此之前，你就单纯的享受编程和创造的快乐好了。

流行谈不上。该用啥还继续用啥。很多业务都是需求密集型的。上来就谈性能，要么是初哥，要么是装13。

ngx_lua 是 openresty 的组件之一，之前在 yahoo／淘宝工作的章亦春同学 @agentzh 现在肉翻到了米国的某公司做 openresty 的全职开发，相当靠谱，另外就是淘宝量子统计的一票人也在国内猛 commit 代码。

node.js 则主要是 joynet 的产物，社区发展速度有目共睹，就不多说了。

从技术实现的层面分析，这两个东西基本上是一码事。因为 nginx + lua 的实质就是 libuv + lua 而 node.js 的实质则是 libuv + javascript 也就是说，都是由一个追求高效的异步 IO 底层加上一个追求高效和小巧的编程语言构成。

两者解决问题的思路也很类似 Non-Block 和 Event-Driven 是最核心的关键词和考虑一切问题的哲学。这是一个编程思路上的跳跃。跟 Erlang 一样，口味比较怪，犯错是必须的，而且不能指望你所有的程序员都能拐得过来这个弯。

从技术包装的层面 nginx 本身是聚焦在 http 协议之上的设施 openresty 这个名称说明了一切。而 node.js 则相对抽象得更底层，可以解决 tcp/udp 等更低层次上的需求。比如说，都可以做网站（HTTP），但 node.js 还可以做 DNS 服务。这也就意味着，后者适用的领域可能要更广泛一些。

两者最适用的场合都是 io 密集型的应用场景。需要说明的是，并不是所有的 web 都可以自动归类到 io 密集型里来的。真正称得上 io 密集的应用场景，其实是相当罕见的。大量的 web 都是需求密集型的（这个词是捏造的，意思是，主要还是业务复杂，而不是其他方面的要求有多高）。当然，为了打压竞争对手而拿这个说事儿，就另说了。

要不要评估和实施 node.js 和 ngx_lua 最主要还是看两点：1，需求本身是不是非得变态的追求性能，2，手里面都有什么样的人。毕竟软件开发是一个经济活动，某个行为的成立首先在 ROI 上就要合理。

不知道是否准确理解了你的问题。

单层的 key-val 结构可以直接用 redis hash 存储 object-id: [key: val, key: val, ...]
多层的 key-val 结构，可以把 key 压平，继续存在 redis hash 里 object-id: [key: val, keyl1.keyl2: val, ...] 根据 redis 的文档，这种结构在 key 的数量很大（超过 255 个以上，有相关配置）时效率开始下降。
层次更多以及 key 的数量不一定的结构，可以参考 full-text-index 的反向索引方案 object-id: [key, key, ...] key: [object-id, object-id, ...] 这等于是自己用逻辑实现了索引。

redis 这类 low level 东西的限制是：只能按 key 来查，没有 key 查询效率就很糟糕。这是坏事（不理解的话，就觉得不好用），同时也是好事（这种限制，显式地表达了索引逻辑，即，没建索引就查询不了）。

@est 晕死，“能联通”和“高效率地联通”肯定不是一码事。有关效率问题，可以看看这个项目的处理 https://github.com/apenwarr/sshuttle/ 提醒：这可能是一个坑，我刚刚才知道，还没来得及细看代码。

@anjianshi @iambeginner

chnroute 是 ip 层的规则，确实省心，而且全局免配置，这是大优点。但要以 vpn 本身不受干扰为前提。如果 vpn 本身就不稳定的话，比如，时不时 reset 要重连什么的，最近比较多见，那就非常坑爹了。

这么做的两个主要动力分别是：

A。省，对没有被 gfw 的网站，是没有必要走 vpn 的，比如，图片，下载之类的，流量那是哗哗地走。尤其是对花钱的 fq 服务，这个比较有意义。如果能做到合理使用，基本上免费套餐的流量就够用了。而这在 chnroute 里是做不到的。

B。快，大部分情况下，如果直连能走通，怎么都比 fq 要快。而，一旦需要 fq 才能访问的，其实用哪种方式速度也差不了太多。理论上的差别，只是理论上的，实际用，真不明显。

对于自建 vpn fq 的同学来说。还有第三个动力：

C。特征小，这个很好懂，用得越少，越不容易被封。比如，我的 ssh-D 配合 pac 因为流量低，很少会遇到 reset 。换成 vpn 我也不希望那么容易就被封。



chnroute 和 pac 的共同问题是“静态规则”，必须手工调整，而且调整起来还很费事，发现问题，定位问题，手工添加，重新加载，测试，调整，这个过程偶尔做一做是很有趣，但是要老做的话，就很蛋疼了。

@est @huazhouji

在服务端确实超级难搞。在客户端真不难。vpn 说到底了也就是一块虚拟网卡，在发数据包时，指定用这个网卡地址做 localAdress 就是，啥多余的事情都不需要做。

原理上不难。

vpn 在客户端的表现形式就是一个网卡，凡是用你 socks5 程序的流量，都通过这个网卡往外发数据就是了。这么做的好处是可以利用 pac 之类的应用层规则，而不是 chnroute 这样的 ip 层规则，也不需要动网关配置。pobi 正在增加这个特性，进行中。

推荐楼主一路 FM 收听当地广播。任何音乐听多了都催眠。

三五百买个简陋的 GPS 接点烟器那种，真心难用，但要靠谱很多。

@virushuo 远离大车的建议＋1

define 北边 first.

@onlybird @momo5269 @chunshuai @shenzhuxi

上面那篇论文我仔细地读过了，说“自动学习”恐怕是有点神化 GFW 了。

大概的原理是这样：抛开端口、数据格式、加密什么的不论，单单从 ip 数据包的层面来看，不管你用的是什么协议。只要你的应用场景最终都是给 browser 用，那么，你数据包的大小、请求密集的时间点、来回次数、间歇，等，这些特征其实都是一样的。那么，我不试图去识别你的每一个数据包，而是试图去识别你通讯的模式，就能知道你是不是翻墙（的 http ）流量，这就是所谓“主机行为特征分析”（欢迎更正我的理解）。再辅以“主动探测”，也就是发个包过去，如果有 http 应答，那就是正常 http 服务，如果没有正常应答（但行为模式却是 http），那就可以高度怀疑是翻墙流量。

基于以上的猜测，比较靠谱的规避手段恐怕是：A，隐藏于正常的 http 流量之中（借用主动探测），B，轮换地使用多个连接（避免触发匹配）。有待其他同学反馈更多信息。

无任何代码，全部 ssh+emacs 搞定。
@m 如需多人协作，各自在自己的目录用 git 管理代码，再指定一个帐户来 fetch/merge 就好了。

如果是以学习和日常开发为目的话，那么 lz 可以 ssh 到 vm 里的 linux 或者 colinux 之类。习惯了之后，再整 real linux 不迟，而且也只用来做 server 就好。

不建议长期把 linux 当作 desktop 来用，因为无论你如何能折腾，终究还是会碰到绕不过去的坎，有那个折腾的时间，还不如多写几行代码。

＊ 付款方点击付款，然后手机会发出“咻咻咻”的声音。

这个声音可以看作是在播送一个调制过的 ROOM URL，它在说，收钱的，我在这个 ROOM URL ，听到请过来找我。

＊ 另外一个手机打开支付宝的个人名片页面。

打开这个页面就会打开话筒，听到和解码付款方播送的 ROOM URL 然后跑到哪个 ROOM 里去。

＊ 付款方手机就能识别出对方手机并建立连接。

双方接上了头，后面的事情就不用解释了吧。