引言

身为币圈一员，又是学计算机专业的，对目前打得火热的两大开源区块链项目 ETH 与 EOS 自然是会比较上心。二者的技术、理念、演化模式、未来前景，都应当是需要关注与思考的话题。

本文将尝试从技术层面对这两个项目进行综合对比分析。一家之言，仅供参考。

Github 项目生态分析

Ethereum 项目主页：https://github.com/ethereum

EOS 项目主页：https://github.com/EOSIO

下面列表分析 ETH 和 EOS 两者的项目生态数据（截至 2018.05.01），同时引入币圈最成功的开源项目 Bitcoin 的数据作为对照。

• 表 1：项目数据总览

• 表 2：核心仓库数据统计

• 注：GPL、LGPL 协议属于非商业化的强制开源协议，MIT 协议是允许项目后续向闭源、商业化发展的。详见这篇文章：如何选择开源许可证？- 阮一峰的网络日志

• 表 3：最近一个月项目开发活跃度

注：这个指标可以直接到 Github 的仓库统计页面上去查看，有详尽的图表与数据展示。结论是，近一个月内，由于主网上线日期临近，EOS 项目开发的活跃程度明显高于 ETH 的两个核心项目。

• go-ethereum 近一个月仓库活动数据查看地址：
  https://github.com/ethereum/go-ethereum/pulse/monthly

• cpp-ethereum 近一个月仓库活动数据查看地址：
  https://github.com/ethereum/cpp-ethereum/pulse/monthly

• EOSIO/eos 近一个月仓库活动数据查看地址：
  https://github.com/ethereum/cpp-ethereum/pulse/monthly

• bitcoin/bitcoin 近一个月仓库活动数据查看地址：
  https://github.com/bitcoin/bitcoin/pulse/monthly

总结：无需对上述数据做过分解读，但从宏观事实出发，ETH 项目的开源生态建设显然优于 EOS。换句话说，没有了中本聪的 Bitcoin 还是 BTC，没有 V 神的 ETH 也还会是 ETH，但没有 BM 的 EOS，可能就不再是 EOS 了。

共识算法优劣对比

BTC 使用的共识算法是 POW（Proof of work，工作量证明）；
ETH 目前使用的共识算法是 POW + POS（Proof of Stake，股权证明）混合模式；
EOS 使用的共识算法是 DPOS（Delegated Proof of Stake，委任权益证明）。

这三种算法各有优劣，POW 模式稳定、游戏规则明确、潜在的人为影响风险最小，为人所诟病的缺陷就是矿场矿池对算力的垄断。POS 是软件模拟挖矿的方案，相对而言整个区块链就更容易被算法漏洞所影响，且账本分叉成本低廉，曾经闹得沸沸扬扬的 ETH 与 ETC 之争就是明证。DPOS 机制是 BM 对 POS 的“技术改进”，其本质上是将 ETH 面临的复杂动态多节点网络问题简化成了固定节点（21 + 100）的简单类静态分布式网络问题。对于程序开发而言，这种简化确实大大降低了开发难度，同时还能有效提高主链的处理能力（即取得较高的 TPS 值）。但区块链项目本来就存在一个“蒙代尔三角”难题：“高效率、去中心、安全性”三者形成一个不可能三角关系：任意系统无法同时满足此三种特性。比特币和以太坊是通过舍弃“高效率”来获得去中心和安全性，而 EOS 则通过 DPOS 机制选举 21 个超级节点，舍弃“去中心”与“安全性”，以“弱中心”方式追求“高效率”。

下表列出的是“按照区块链网络内置协议运作的话，三种算法各自可能面临的安全问题”：

• 表 4，PoW、PoS、DPoS 安全性对比

注：详情参见这篇文章：PoW，PoS，DPoS 综述

结论：从现有技术角度看，ETH 目前的 POW+POS 混合模式无疑是最佳选择。接下来，阐述得出该结论的原因。

对共识算法机制的引申思考

由上表可知，技术上，POW 算法可以免疫绝大多数的攻击手法，而 POS 算法最易遭受攻击。然而，这里有一个大前提，就是攻击者是遵守“游戏规则”的，会在区块链自身设定的协议体系中找出漏洞并且尝试攻击。但实际上，没有这么傻的攻击者。打个比方，我知道小偷可能会撬门而入，所以安全防范措施就是换好的防盗门，加坚固的锁。殊不知，真正要来偷的都是走窗户和阳台，或者假扮外卖小哥入室抢劫，根本不会按套路出牌。在一个点对点的网络系统中，有效节点的数量决定了整个系统的健壮性。BTC、ETH 都是不限全节点数量的，主链网络安全又受到矿工们巨大算力的保护，所以可以长期稳定运行。但 EOS 的架构设计，不具备这个条件。

我们知道，EOS 的架构是 21 个超级节点负责提供整个主链所需的运算、存储、网络等硬件资源，而 100 个见证节点是“预备队”，平时只负责验证超级节点是否正常、有效的工作，只有当某个超级节点出现问题时，才有机会被选上成为新的超级节点。原本这是一个很优秀的主从备份设计，可以确保整个网络的稳定运行。可惜，当 EOS 的分红机制将超级节点设计成“会下金蛋的鸡”之后，事情就变质了。设想这样一个场景，我是某个见证节点的主人，每个月都花费不菲的成本去运行这个备份节点，眼见着超级节点躺着赚钱，自己这却只能跟着喝口汤。明明是一样的硬件配置，一样的设备开销，一样的运维费用，只因为你当初主网上线时选票拉的好了那么一点点，坐上了超级节点的宝座，从此就吃香的喝辣的，凭什么？按照游戏规则，见证节点作为备份，只有当某个超级节点宕机死掉之后，才有机会被选上代替这个超级节点的位置。100 个见证节点，如果大部分都对超级节点抱着“你赶紧死掉我好上位”的心态的话，我不知道有什么理由阻挡超级节点被恶意攻击。事实上，只要对某个超级节点暴露在外网、对主链提供服务的端口发动 TCP/IP 层的大流量 DDoS 攻击，这个超级节点的网络服务能力就一定会被瘫痪掉。几分钟后，这个一直处于无法响应通信状态的超级节点就会被票死，失去超级节点的资格。要是所有节点持有人都这么干，EOS 网络就没法工作了。

当然，出钱的资本方都不傻，这样自己玩死自己的蠢事不会去做。那这 100 个见证节点真的就会遵守规则，面对潜在的巨额利润毫不动心，乖乖排队等待不知何时才会落到自己头上的超级节点资格吗？主网还没上线，超级节点贿选的事情就已经发酵了，ETH 的 创始人 V 神还专门为此事写了一篇檄文：V神谈EOS节点投票：我们必须绕开的阴影之地。主网上线之后，121 个节点实际上就形成了一个利益共同体。当所有参与方都意识到自己既有毁灭对手的能力，又随时可能被对手所毁灭的时候，博弈的结果只能是联合起来，一起赚钱，一起割韭菜。但事情若走到这一步，EOS 这个区块链项目和某个大互联网公司的云计算平台还有什么区别呢？以后这 121 个节点中的大部分肯定都是跑在亚马逊 AWS 云服务器上的，我作为一个开发者，与其在各方利益纠葛不清的 EOS 系统内去费时费力的开发 DAPP，还不如直接用成熟的 AWS 系统，快速开发快速上线呢。

此外，有攻击超级节点动机的可不止那 100 个见证节点持有人。EOS 代币已经被炒到了一个高位，就是普通黑产，也有强烈的通过威胁攻击超级节点，来向超级节点持有人敲诈勒索大量加密货币的动机。目前全球各地天天专研 ETH 系统漏洞，指望盗币发财的黑客一大堆，攻防战早已打响，ETH 也在开源社区自身力量的驱动下不断的优化协议逻辑，修改代码 BUG。而 EOS 呢，主网都没上线，未知的考验还不知有多少。欲带皇冠，必承其重，EOS 这种先把泡泡吹起来，再去试探真假，把赌注压在六月主网上线之后一切顺利的做法，风险极高！

一点补充分析

实际上，EOS 的预期已经被过度消耗了。项目八字还没一撇，就这样去爆炒，完全是资金盘操纵的手法。到时候主网上线，随便出点什么差错（这是大概率事件，一个新系统上线，其表现是几乎不可能完全符合预期的），就都是做空的动力。

我比较赞同这篇文章所提出的理论：

区块链是什么？
区块链是比特币；
区块链是点对点的分布式的账本；
区块链是带智能合约的点对点的分布式账本；
区块链是生产关系；
区块链是一种社会思潮；
区块链是一种基因（X-gen）

不错，区块链就像细胞中的 DNA。其核心价值，不在于主链有多么强大的而丰富的功能，而在于其像基因一样，去中心化，稳定，传承价值，同时具备一定的合约功能。而更为复杂的功能，就应该交给侧链、分支去实现，就像自然界发生的那样：基因转录出 RNA，RNA 表达出蛋白质，再由蛋白质去承担生命活动。我相信自然的选择，这才是区块链技术正确的进化方向。

引言 - 心意相合，神思相安

或曰：“以德报怨，何如？”
子曰：“何以报德？以直报怨，以德报德。”
　—— 《论语·宪问》

子曰：“吾十有五而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十而从心所欲不逾矩。”
　——《论语·为政》

心与意相合是个什么样的状态呢？抛却道儒间的门户之见，《论语》中的这两段就很好的诠释了“心与意相合”。

先做个名词解释。中医，或者说道家里讲的“心”为何，“意”又为何？

心者，君主之官，神明出焉。 ——《黄帝内经·素问·灵兰秘典论》
五脏六腑之大主也，是精神之所舍也。 ——《黄帝内经·灵枢·邪客篇》

中医所谓的“心”，并非单指心脏，而是指一个与人的精神、情志密切相关的系统，是五脏六腑的“君主”。用解刨学的观点看，“心”大致等于心脏+神经系统+内分泌系统的综合体；从心理学的角度看，心更类似于潜意识，是“灵魂”的代名词。

“意”则特指显性的“意识”，是后天习得的一系列东西，包括法律、道德、礼教、人情世故、利益考量等等。这些后天习得的内容必须一分为二的看待，那些有普世价值的，也就是与绝大多数人大脑中天生预装的操作系统相契合的东西，就是正确的，比如自由、民主、公正、法制、富强。而若以特定利益考量为目的强行灌输的“意”，就是糟粕、垃圾，比如天朝小学生守则里写有的“爱国等于爱党”、米帝如今风行的“政治正确”等。

徐文兵老师曾在二〇〇九年中国之声播出的《国学堂》节目中谈过，为人处世，最痛苦不过的就是心与意相违逆，身体里总有两个自己在掐架，长此以往，危矣！下面把这段音频放上来，读者听罢，可自行体悟“心与意”的关系：

正文 - “痛经也有可能是心病”学习笔记

“痛经也有可能是心病”是厚朴中医学堂在沪江 CCTalk 上直播的“痛经的非药物外治法”网络课堂讲座的姊妹篇，全程录音长度 72 分钟，讲义同样只有一张 PPT。
注意：这是一期从心理治疗层面入手，可能达到根治痛经的效果的节目。

第一篇：导致痛经的心理因素

1. “求关注”的心理（因病获利）
   • 问题可能始于母女关系，发展于恋爱关系。根本原因还是缺爱、不安全感、渴望温暖。“一个人若愿意承受非常大的痛苦去获取一丝一点的温暖，则足以说明 Ta 对温暖渴求的迫切程度。”

2. 痛经成为一件“未竟之事”
   • 当痛经成为了一种“自我实现的预言”，“恐惧”与“潜意识的期盼”交织，“月经”与“痛”就成了一种绑定关系。心焦则气乱，最后便造成了“不痛反而不正常”的情形。

3. 与母亲的关系及女性身份认同
   • 与母亲的关系好吗？
   • 对女性身份的认同感如何？
   • 同性恋的人越来越多，绝大多数原因都是性别认知失调；
   • 身心一体，长期的负面情志积累会导致身体上严重的疾病。

4. 精神压力
   • 生活或者工作环境导致的长期焦虑、不放松；
   • 某次创伤性事件与痛经关联起来了，导致后续持久的痛经问题；
   • 成年后的情感创伤，导致十二正经中“环阴气”的肝经、肾经行气不顺。“谈恋爱不仅走心，还走肾”，两性情感问题是与痛经直接相关的。

以下是这一篇的讲座录音：

第二篇：对身体造成的影响

1. 器质性的妇科疾病，如子宫内膜异位症、子宫息肉、子宫肌瘤、子宫腺肌症以及乳腺方面的疾病等；

2. 气血两虚，肝气於滞，脸色蜡黄、长斑、长痘等。

以下是这一篇的讲座录音：

第三篇：心理疏导的方法

1. 重塑自我认知
   • 欣赏自己，不必示弱；
   • 自我关怀，不必求人；
   • 在痛经的过程中，分散自己的注意力；
   • 痛经的过程其实也是自我调整的机会，做积极的事，不要作。

2. 阴阳调和
   • 两性关系的调和；
   • 更大范围上的“阴阳调和”，与自己、他人、周围环境、宇宙自然的调和，即道家所说的“法于阴阳，合于术数”^[1]。

3. 接受身份认同
   • 作为女性，对自我性别的认同感、自豪感；
   • 真正的强大只能源自内心，温暖是求不来的，委曲求全的而来的温暖也不是温暖；
   • 当情志创伤太重，仅凭自己走不出来的时候，不要死扛，应及时求助于专业人员。

以下是这一篇的讲座录音：

第四篇：课堂答疑，回答学员的问题

医案实例，答疑解惑。末尾提到点按膻中穴、揉小腹、坚持自我艾灸等外治法，上节课已有详述，可以复习一下。
以下是这一篇的讲座录音：

引言 - 为什么我们还在“信中医”

面对现代医学无法给出明确有效治疗方案的病症，我们应当求助于遵守循证医学原理的传统中医。
观点提炼于：
　——《太医来了》首席太医，丁香医生医学总监，田吉顺老师 ^[1]
　——《天方烨谈》主讲，华大基因 CEO，尹烨老师
　—— 我的道家引路人，厚朴中医学堂堂主，徐文兵老师

为什么“信中医”？答案很简单，信的不是中医，而是 循证医学（Evidence-based Medicine）。现代医学的边际之外，还有很多很多未解的医学难题。优秀的中医，可以通过多年的循证临床研究，凭借己身对“道”的理解，从另一个科学暂且未达的角度，（部分）解决这些难题。

话说，最近《黄帝内经》中关于十二时辰的子午流注学说都在基因的生物钟控层面被重新发现了，还有什么不可能的呢。^{[2] [3]}

中医，或者说循证医学，最大的缺点就是太个例化、对医者甚至病人都有很高的要求，且难以用双盲实验的手段大规模重复验证，这与工业文明的手法相悖。总之，这种缺点导致的事实就是绝大多数中医院校里培养出来的“中医”，都是庸医。于是，总的来说，中国目前的中医体系完全比不上条件、规则、方案都相对固定，可验证可重复的西医体系。何况，传统中医体系里，真正的大医，同时也应该是“有道高人”。这样的人，本就凤毛麟角啊。

可惜现代医学体系毕竟力有所限，很多时候遵守循证医学才是正途。所以，选择信中医，其实信的是那个有着多年循证经验的医者，比如徐文兵老师。（这里帮徐老师宣传一下，微信公众号hopexuwenbing，长达两学年的免费医道教学内容，干货满满；厚朴中医学堂淘宝店：https://hope-life.taobao.com/，十年五皇冠金牌老店，值得信赖，艾灸器、刮痧片等家用小部件一应俱全。）

鄙人于二〇〇九年在中国之声《国学堂》节目里听到梁冬和徐文兵老师讲《黄帝内经》，徐老师那精妙非常的讲解，令人颇有当头棒喝，茅塞顿开之感。始知华夏大地上的道家传承，从未断绝。而今九年时光匆匆，理论、经验、实修相互验证，益发明了“道”之所指。确实，宇宙之最不可理解之处，就在于它是可以被理解的。梁冬作为一个深受徐老师影响的经济媒体主持人，亦始终未曾放下对道家的研究。今年三月初，《天方烨谈》节目播出了尹烨与梁冬在《觉者》上关于“意识如何影响生命”的探讨，听罢可知，梁冬自己的修行也已经比九年前高了不止一筹。更难得的是，这期节目证实了我之前的一个猜测：华大基因的 CEO 尹烨老师，他绝对也能算道家的，是一路人。

从基因到意识，万法归宗，不论科学还是玄学，原来它们研究的都是宇宙真理，也就是那唯一的“道”。真理只有一个，“道”只有一条，人所能做的，也不过是用这短暂的一生不断去追寻罢了。

废话不多说，下面回归本文正题：

正文 - “痛经的非药物外治法”学习笔记

“痛经的非药物外治法”是厚朴中医学堂在沪江 CCTalk 上直播的一期网络课堂讲座，全程录音长达 87 分钟，讲义倒是只有下面这一张 PPT。中医讲究口传心授，PPT 上列个纲要也就够了。

第一篇：中医如何看待痛经

1. 痛经分类：原发性痛经和继发性痛经。两种情况的治疗方案是完全不同的。
   • 原发性痛经在临床上难以诊断出明确的病因，现代医学目前相对有效的治疗方案就是口服短效避孕药，嗯，典型的治标不治本；
   • 继发性痛经通常由妇科的器质性病变所引起（如子宫内膜异位症、子宫肌瘤），这类必须先治好病症。

2. 对于非器质性病变的痛经，中医将其分为五个方面：
   • 肾气亏损型。这类属于虚症，肾气先天不足或者后天耗损过度所至，外治法以艾灸补益为主；
   • 气血虚弱型。这类与单纯的肾气亏虚不同，已经到了虚不受补的状态，同是艾灸治疗，需要远端取穴，循序渐进；
   • 气滞血於型。这类临床较多见，就是体内堵了不该有的东西。病因更多与“情志”相关，肝气不顺则易怒，实为心病外现之症。外治法，肝经区局部刮痧，艾灸膻中穴；
   • 寒凝血於型。这类是寒症，临床患者偏年轻化，冷饮、碳酸饮料吃多了，或者冬季穿的太少，夏季空调吹太多，经年累月而成。外治法，每天坚持热水泡脚，最好是煮花椒水泡；膀胱经、冲脉等处刮痧祛寒毒，再辅以艾灸；
   • 湿热蕴结型。表现为小腹倦痛，经期量多且长。外治法依然可用刮痧，以去湿热为主要目标。

以下是这一篇的讲座录音：

第二篇：外治法如何解决痛经

1. 经前乳胀——乳腺按摩
   • 不要用不专业的手法瞎按摩，不但无益，反而有害；
   • 好的按摩师手上应该有“气感”，会找到“关键点”；
   • 情志变化的累积带来生理变化，会导致肋间隙的“千千结”，这些都需要通过“导引按跷”^[4]的手法来打开；
   • 自我按摩是可行的，但对“正常状态”的正确自我认知很重要。

2. 痛经的艾灸疗法
   • 艾灸的热度有穿透力，这是普通热水袋所不能比的；
   • 灸法，光靠艾灸的热度暖起来是不够的，快速见效须得做到“气至病所”；^[5]
   • 持之以恒，量的积累很重要；
   • 双灸，远端取穴，如灸足三里；
   • 单灸，就近取穴，灸关元、子宫穴或者直接灸痛点；
   • 快速缓解疼痛的症状，可直接点按足三里；
   • 补充单灸取穴的方法：
     • 气滞血於型，就近取穴之外，加灸膻中、太冲穴；
     • 寒湿凝滞型，加灸地机穴；
     • 气血虚弱型，加灸足三里；
     • 肾气亏损型，加灸太溪穴。

3. 月经期能否刮痧或者导引按跷
   • 正常情况下是不可以的；
   • 面对急症、相对严重的疼痛等情况，则重症须下猛药，刮痧或按跷手法都是可取的，但必须谨慎小心；
   • 经期不适合用手法，但行经前却是艾灸和导引按跷的良机。平时保养的效果可以在经期的流量和实际感觉中得到反馈。

4. 女性朋友应该注意的保养之道
   • 注意保暖，脚踝、小腿、腰腹都是容易受凉的部位；
   • 经期少洗头，若不得不洗，做好保暖工作并及时吹干；
   • 贴身衣物选纯棉的；
   • 小偏方：醪糟蛋汤、红糖姜汤、粗盐袋热敷等；
   • 止疼药除非逼不得已，否则别吃，会掩盖病症，造成依赖；
   • 总结：知妄守常，No Zuo No Die

以下是这一篇的讲座录音：

第三篇：医案描述，分享几个临床病例

医案实例，文字难以尽述，此处直接上音频吧。只提几个要点：

• 三十岁前人找病，三十岁后病找人；
• 本宇宙的基本法则——出来混，迟早是要还的；
• 减肥不能不吃主食，植物种子中蕴含着巨大的能量，是最好的补品；
• 了解自身，顺应自然。

以下是这一篇的讲座录音：

第四篇：课堂答疑，回答学员的问题

学员们的问题着实是千奇百怪……不做赘述了。

以下是这一篇的讲座录音：

本文介绍目前现代密码学的最先进技术，
前半部分主要翻译自 《Cryptographic Right Answers》，附上收集的资料，和byron个人的理解。

密码学理论艰深，概念繁多，本人知识水平有限，错误难免，如果您发现错误，请务必指出，非常感谢!

下文分类介绍在各种适用场景下，你应该使用的现代密码学算法

加密数据

按照优先级，应该选择:
(1) 首选 NaCl库，或者libsodium库，使用里面的crypto_secretbox()/crypto_secretbox_open() 函数
(2) Chacha20-Poly1305 算法
(3) AES-GCM 算法

适用场景:当你需要避免把明文数据在网络上传输的时候。

以上3种算法，都是AEAD类的算法，AEAD是2015年最好的选择。
其中的(2)和(3)在结构上类似：一个流加密模式的算法，配合一个多项式结构的MAC。
(2)是一个流加密算法，配合一个为通用cpu优化的MAC算法，
对密码学库的实现者来说，Poly1305也比GCM更容易安全地实现。
AES-GCM是工业标准(TLS目前主要用的就是AES-GCM)，现代CPU通常都有专门为AES-GCM设计的硬件指令，但是在没有硬件指令支持的CPU上(比如32位的arm)，(3)性能低于(2)。

此外，应该

• 避免AES-CBC
• 避免AES-CTR
• 避免64bit块大小的块加密算法–(说的就是你–BlowFish)
• 避免OFB模式
• 不要使用RC4，RC4已经被攻破

对称密钥长度

选择使用256bit长度的密钥

适用场景：只要你在使用密码学，你就应该注意对称密钥长度

请记住：不要把对称加密（如AES）的key长度，和非对称加密(如RSA)的key长度搞混淆了，对称加密的key通常比非对称加密的key短多了。

下表对比了相同安全程度时，不同算法的密钥长度，单位:bit

此外，应该

• 避免使用巨大key的算法(使用远大于256的key，只能说明使用者没有安全概念)
• 避免把多个加密算法串联叠加起来使用，这并没有什么卵用
• 避免128bit以下的key长度(比如，哥们求你别再提DES这种56bit密钥的古董了)

对称签名

应该选择 HMAC 类的算法

适用场景：安全加固一个API，如各种开放API的调用方认证

如果对一个API，你需要做认证(authenticating)，但是不需要做加密(encrypting)，记得千万不要自己发明算法，你自己发明的MAC算法基本都有安全漏洞，如果不信，请Google一下 "长度扩展攻击"
长度扩展攻击
Flickr的漏洞案例

同时，必须要注意的是，要使用一个常数时间字符串对比算法（这个地方和码农的常识完全相反，请务必留意）

此外，应该

• 避免自行设计的“带密码的hash”结构，你的设计基本都是有安全漏洞的
• 避免HMAC-MD5，避免HMAC-SHA1，使用HMAC-SHA256, HMAC-SHA512等
• 避免复杂的多项式MAC
• 避免加密hash值的结构
• 避免CRC

Hashing/HMAC 算法

应该选择SHA2类的算法:: SHA-256, SHA-384, SHA-512, SHA-512/256

优先使用 SHA-512/256，SHA-512/256这个算法把 SHA-512 的512bit输出截短到256bit，避开了length extension 攻击。
同时，目前SHA-2是很安全可靠的，你不需要升级到SHA-3.

此外，应该

• 避免SHA-1
• 避免MD5
• 避免MD6

随机ID

应该使用256 bit的随机值

一定要使用 /dev/urandom，请认准这个

此外，应该

• 避免用户空间的随机数生成器如:havaged,prngs,egd,等
• 避免/dev/random

密码处理

按照优先级顺序,选择：

• scrypt
• bcrypt
• 如果以上2个都没有，那就用PBKDF2

此外，应该

• 避免直接SHA-2
• 避免直接SHA-1
• 避免直接MD5

非对称加密

应该使用NaCl库

适用场景：当你需要加密消息，发给陌生人，并且对方异步接收消息，做离线解密时。这是一个很窄的应用案例，这种用法有个名字叫电子信封(digital envelope)，典型比如gpg加密文件后发送。

这条是几条之中最难做正确的，不要使用底层的密码学库，比如OpenSSL或者BouncyCastle。

你应该停止使用RSA，并且切换到椭圆曲线类体制，原因是：

• 对RSA的攻击能力的进步 — 定义在传统质数域上的乘法运算(应用包括DH,DSA,ElGamal等)，要比椭圆曲线域上的乘法运算快得多。这是由于质数域上数域筛法（number field sieve,NFS）的进展，而在椭圆曲线域上，没有NFS这类算法。
• RSA (和DH) 或迫使你考虑“向后兼容性”，而椭圆曲线体制没有这种兼容性包袱。TLS最近的几个安全漏洞，部分愿意也是由于这种向后兼容性，导致已经被破解的陈旧算法存在
• RSA在一般场景中，都是直接用公钥做非对称加密，这种用法丧失了前向安全性(Perfect Forward Secrecy)。而椭圆曲线就不提倡，也很难这样使用，这样你就不会害死自己了。
• 在椭圆曲线体制下，保证正确性和安全性的重任，主要由密码学家承担，密码学家会提供一组曲线参数，在某一性能水平下，针对安全性和性能做优化。这样程序员不容易误用而害死自己。在RSA体制下，正好相反，程序员必须提供参数来保证正确性和安全性，就算是RSA-OAEP这种很好的设计，程序员也必须知道怎么提供参数，这样程序员很容易搞错。

如果你必须使用RSA，一定要使用RSA-OAEP with SHA256，指数使用 65537

• 避免 RSA-PKCS1v15
• 避免 ElGamal
• 避免 RSA

非对称签名

应该使用NaCl，Ed25519，或者RFC6979

应用场景：如果你在设计一种新的比特币，或者一个给Ruby Gems或者Vagrant imges文件签名的系统，或者数字版权保护系统(DRM)，其中一系列的文件需要离线做认证；
或者你在设计一个加密消息传输层

上一条的内容在此处全部适用。

在10+年做付费软件安全评估的工作经历中，我只有屈指可数的几次，遇到使用RSA-PSS的用户，RSA-PSS是一个学术界的推荐算法。

过去10年，非对称签名最主要的应用场景是比特币，和前向安全的密钥协商（TLS协议里面的ECDHE）。
其中最主要的算法全都是基于椭圆曲线体制的。务必警惕新出现的使用RSA签名的系统，很有可能有问题。

在过去几年中，业界有一种趋势：放弃传统DSA签名，改为难以误用的确定性签名体制，其中的EdDSA(不要和ECDSA搞混了喂！)和RFC6979是最好的例子。这种趋势的主要是受到2010年索尼PlayStation 3的 ECDSA私钥被破解事件的影响，在这个案例中，索尼公司的码农错误地把一个随机数重复使用来做ECDSA签名，形成了漏洞，使得破解者据此直接把私钥算出来了。确定性签名体制在设计中不再依赖随机数生成器，因此彻底避开此类误用。所以你应该优先使用确定性签名体制。

• 避免RSA-PKCS1v15，避免RSA，避免ECDSA，避免DSA
• 特别要避免常规的DSA和ECDSA

Diffie-Hellman 密钥交换

应该使用NaCl，Curve25519，或者DH-2048

适用场景:如果你在设计加密消息传输系统，并且无法使用固定对称密码

这是很棘手的一条，主要考量如下：

• 如果你能使用NaCl库，那就使用NaCl库。你甚至不需要管NaCl是什么。
• 如果你能使用一个可信赖的第三方库，那就使用Curve25519，这是一条现代的ECDH曲线，有丰富的开源代码，性能经过高度优化，被彻底地安全分析过。并且Curve25519即将进入TLS 1.3版本标准。
• 但是绝对不要自己实现Curve25519，也绝对不要自己移植Curve25519的C代码
• 如果你不能使用第三方ECDH库，但是可以使用DH库，那就使用DH-2048，使用1个标准的2048 bit的群。
• 但是不要使用传统的DH，如果你需要协商DH参数，或者和其他实现互操作
• 如果你一定要做握手协商，或者和旧软件互操作，那么考虑使用NIST P-256, NIST P-256 有广泛的软件支持。
• 写死在代码里的DH-2048参数，比NIST P-256更安全。NIST P-256比协商出来的DH更安全。
• 但是，由于NIST P-256的实现有一些陷阱，所以一定要谨慎选择可信赖的，广泛使用使的第三方库
• P-256 可能是NIST曲线中最安全的，不要使用P-224。

DH（密钥协商）算法确实很难用，但是它很重要。

• 避免，传统常规的 DH, SRP, J-PAKE 握手和协商
• 避开任何只使用了块加密算法和srand(time())的密钥协商模式（肯定有漏洞）

网站安全

应该使用OpenSSL，或者Google的BoringSSL，或者直接使用 AWS的 ELB

此处网站安全，指的是让网站支持HTTPS协议。
如果你不能把这个任务交给Amazon的云服务去做，把难题留给Amazon去解决，那么OpenSSL目前仍然是正确选择。

• 避免不常见的TLS库，例如polarssl，GnuTLS，MatrixSSL等

客户端-服务器结构的应用程序的安全

应该使用TLS

适用场景：如果你以为自己理解了前面关于公钥加密的介绍。。。

通常，在你设计了自己的RSA协议之后的1至18个月，你肯定会发现，你犯了某个错误，使你的协议没有任何安全性。
比如Salt Stack，Salt Stack的协议使用了 e=1 的RSA 公钥。。。

听起来，TLS有下面这些黑历史：

• The Logjam DH negotiation attack
• The FREAK export cipher attack
• The POODLE CBC oracle attack
• The RC4 fiasco
• The CRIME compression attack
• The Lucky13 CBC padding oracle timing attack
• The BEAST CBC chained IV attack
• Heartbleed
• Renegotiation
• Triple Handshakes
• Compromised CAs

但是，你仍然应该使用TLS做传输协议，因为：

• 这些漏洞中的大部分，仅仅是针对浏览器的，因为他们依赖受害者执行攻击者控制的JavaScript脚本，这些JavaScript脚本生成重复的明文，或特定的明文。
• 这些漏洞中的大部分，其影响都可以被减轻，只需要你在代码和配置里面写死 TLS v1.2, ECDHE，和 AES-GCM就行。这听起来很棘手，但是这远远没有你自己设计使用ECDHE和AES-GCM的传输协议棘手。
• 在一个自定义的传输协议的场景中，你并不需要依赖CA，你可以用一个自签名证书，嵌入到你的客户端里面。
• 不要自己设计加密传输协议，这是极其困难而易错的工程难题
• 使用TLS，但是不要使用默认配置

在线备份

应该使用Tarsnap

名词解释

本文的内容比较新，相关中文资料极少，因此文中的名词对读者可能有点陌生，故byron这里介绍一下文中提到的一些名词：

• NaCl 库：
  http://nacl.cr.yp.to/
  是密码学学术权威 Daniel J. Bernstein教授 设计的一个密码学算法库，2008年发开始公布。NaCl的特点是：api简洁而易用，高性能，高安全性，主要用于网络通信，加密，解密，签名等，NaCl提供了构建高层密码学工具的核心功能。

• libsodium 库：
  https://download.libsodium.org/doc/
  libsodium是对NaCl库的一个分支，进一步改进接口易用性，和可移植性。

• AEAD :
  https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
  AEAD的概念：
  在通常的密码学应用中，Confidentiality (保密) 用加密实现，Message authentication (消息认证) 用MAC实现。这两种算法的配合方式，引发了很多安全漏洞，过去曾经有3种方法：1. Encrypt-and-MAC 2.MAC-then-Encrypt 3.Encrypt-then-MAC ，后来发现，1和2都是有安全问题的，所以，2008年起，
  逐渐提出了“用一个算法在内部同时实现cipher+MAC”的idea，称为AEAD(Authenticated encryption with additional data)。
  在AEAD这种概念里，cipher+MAC 被 一个AEAD算法替换。
  http://en.wikipedia.org/wiki/Authenticated_encryption

• ChaCha20-poly1305 :
  ChaCha20-poly1305是一种AEAD，提出者是Daniel J. Bernstein教授，针对移动互联网优化，目前Google对移动客户端的所有流量都使用ChaCha20-Poly1305

• AES-GCM :
  AES-GCM是一种AEAD，是目前TLS的主力算法，互联网上https流量的大部分依赖使用AES-GCM。
  AES-GCM和ChaCha20-Poly1305的性能对比测试结果：

| Chip| AES-128-GCM speed| ChaCha20-Poly1305 speed|
| ------ | :-----: | :-----: |
| OMAP 4460| 24.1 MB/s| 75.3 MB/s|
| Snapdragon S4 Pro|41.5 MB/s| 130.9 MB/s|
| Sandy Bridge Xeon (AESNI)|900 MB/s| 500 MB/s|

• SHA2 :
  http://en.wikipedia.org/wiki/SHA-2

• Curve25519 :
  http://cr.yp.to/ecdh.html
  Curve25519 是目前最高水平的 Diffie-Hellman函数，适用于广泛的场景，由Daniel J. Bernstein教授设计。由于NIST P-256的设计过程不透明，有来历不明的参数，被广泛怀疑有后门，所以设计了Curve25519，Curve25519的设计过程完全公开，没有任何来历不明的参数。
  部署情况：http://ianix.com/pub/curve25519-deployment.html

• Ed25519 :
  http://ed25519.cr.yp.to/
  Ed25519 是一个数字签名算法，优点有：

  • 签名和验证的性能都极高， 一个4核2.4GHz 的 Westmere cpu，每秒可以验证 71000 个签名
  • 安全性极高，等价于RSA约3000-bit
  • 签名过程不依赖随机数生成器，不依赖hash函数的防碰撞性，没有时间通道攻击的问题
  • 并且签名很小，只有64字节，公钥也很小，只有32字节。

  部署情况：http://ianix.com/pub/ed25519-deployment.html

• 前向安全性：
  前向安全性( Perfect Forward Secrecy )
  http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
  前向安全性指的是，如果攻击者抓取并保存流量，那么将来私钥泄露后，攻击者也无法利用泄露的私钥解密这些流量。

• Diffie-Hellman 密钥交换：
  http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
  在任何一本密码学教材里面都会重点介绍的

• constant time compare :
  针对Timing attack，http://en.wikipedia.org/wiki/Timing_attack （这种攻击真是脑洞大开！）
  当一个算法的运行时间和输入数据有关的时候，可以根据运行时间这一信息，破解出密钥等。
  典型的，比如要验证一个对称签名，如果你用了C库里面的memcmp()，那你就会被timing attack方式攻击。
  因此，涉及到密码学数据的memcmp，必须要用运行时间和输入无关的函数，比如OpenSSL库里面的CRYPTO_memcmp()

原文链接：https://gist.github.com/byronhe/232d22f1d3dcaa0a20cb

XX-Net 简介

XX-Net 继承于 Goagent，实用之处在于它集成了自动扫描与检测可用的 GGC(Google Global Cache) IP 段功能，让基于 GAE 的翻墙方案得以长期稳定的坚持下去。项目主页：https://github.com/XX-net/XX-Net

XX-Net的安全性

先下结论：XX-Net 不能用于匿名，但可以保证数据传输的安全。

下面详述：

1. 由于免费 GAE 应用无法使用 socket 接口，基于 GAE 的翻墙代理都要导入根证书，从而在本地完成对 https 流量的劫持、解密与转发，XX-Net 也不例外。由于 XX-Net 在首次启动时是在本地随机生成自签发证书的，只要这个唯一的本地证书不泄露，就不存在证书被盗用，进而遭受中间人攻击的风险。所以，如果有分享自用的 XX-Net 软件包给朋友使用的需求，请记得删除data/gae_proxy目录下的CA.crt根证书和certs目录。
2. XX-Net 本地客户端到 GAE 服务器的连接，默认检查扫描到 Goolge IP 的 https 证书，这是防蜜罐节点和墙的中间人攻击。所以，客户端到 GAE 服务器的连接是安全可靠的。
3. GAE 服务器到目标网站的连接，默认没用开启对 https 证书的检查，因为墙无法干扰到。为了加强安全性，可以手动开启：
   定位到 XX-Net 所在目录下的
   gae_proxy/local/gae_handler.py
   文件，搜索
   kwargs['validate'] = 0，
   将值改为= 1即可。
   测试：开启服务端证书验证后，通过 XX-Net 代理访问
   https://goagent-cert-test.bamsoftware.com/，
   返回报错信息：
   SSLCertificateError('Invalid and/or missing SSL certificate for URL: https://goagent-cert-test.bamsoftware.com/',), should validate=0 ?
   这样一来，GAE服务器到目标网站的连接也可以确保安全。
4. 关于匿名与隐私的问题，参见项目说明文档：
   https://github.com/XX-net/XX-Net/wiki/Anonymity-and-Security
   总之，如果传输、浏览特别敏感的信息，请使用 Tor，并学习如何匿名。而普通用户，只需要部署自己的 appid，且 appid 命名不要与现有网名相关，这就足够了。

扫描高速 GGC IP 段

XX-Net 保证其高可用性的核心技术就是扫描 GGC IP 段并维护动态的可用IP连接池。所以，指定的待扫描 GGC IP 段的质量就决定了 GAE 代理访问的速度。于是，问题的关键在于：如何发现高速稳定的 GGC IP 段。

• 工具：checkiptools，项目主页：https://github.com/xyuanmu/checkiptools

• 过程：

  1. 找寻目标国家，最好是与中国的国际出口线路有海底光缆直连的。比如台湾，日本，韩国，马来西亚。具体可以参考这个网站：http://www.submarinecablemap.com/
  2. 在 checkiptools 目录下，获取目标国家的全部 IPv4 地址段：

  1	wget -O- 'https://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest' | grep ipv4 | grep KR | awk -F\| '{ printf("%s/%d\n", $4, 32-log($5)/log(2)) }' > googleip.txt

  这个例子中，grep KR用到了韩国的 ISO 标准国家代码KR，所有的 ISO 标准国家代码参见 Wiki：https://zh.wikipedia.org/wiki/ISO_3166-1

  3. 开始扫描。Windows 下，直接双击运行checkip.bat，扫描目标国家的所有IP段，确认其是否为 GGC 服务器。扫描超时参数可以通过修改python/checkip.py文件里

  1 2	g_conntimeout = 5 g_handshaketimeout = 7

  的值来自定义，单位为s，其他参数可参考代码注释自行调整。

  4. 提取有效IP段。Windows下直接双击运行!ptools.bat，按照提示操作，选 2：提取 ip_tmpok.txt 中有效IP的IP段, 并生成 ip_output.txt，并设定延迟过滤阈值，如400ms。
  5. 将生成的 ip_output.txt 文件内容复制并在 XX-Net 的 Web 设置页面提交。待 XX-Net 扫描一段时间后，访问 Youtube 测速。如果确实高速稳定，则保留这些 GGC IP 段。

• PS：如果手头有 VPS 的，可以在 VPS 上开个300线程暴力扫描，再将得到的 GGC IP 段在本地网络用 checkiptools 检查一遍，得到靠谱的高速 GGC IP 段。

5月12日，在黑客大赛GeekPwn澳门站现场，来自美国加州大学钱志云团队的博士生曹跃现场展示了惊人的“远程任意TCP劫持连接技术”，重现了著名黑客米特尼克在互联网任意地方劫持任意用户的传奇。攻击的技术细节没有完全公开，但是根据GeekPwn的相关报道来看，曹跃同学是使用了一种被称为边信道（又称侧信道）攻击的技术完成了这一壮举。

今天我们抛开这个深奥的漏洞，来谈下什么是边信道攻击。很多工业界的同学可能对这个学术界的热门术语并不是很熟悉。在密码学中，针对加密电子设备在运行过程中的时间消耗、功率消耗或电磁辐射之类的侧信道信息泄露而对加密设备进行攻击的方法被称为边信道攻击定时信息。这种攻击方式目前也已经被广泛的应用到密码学之外的安全技术领域。

一个现实生活中的边信道攻击案例

几年前有过这样的一个报道：南京大学学生刘某在观看一段记者采访某互联网公司总裁周某的视频时突发奇想，利用视频中记者采访时的拨号声音还原出了周某手机号码。这个事情引起了网友的围观，并被周某在在微薄上证实确有其事。这个事件中刘同学使用的就是边信道攻击，通过记者视频中拨号的声音，对照每个号码按键声音的标准音，就可以精确的还原出真实的号码。

在网络攻防中，边信道的思路实际已经有比较广泛的运用，比如通过电磁木马窃收物理隔离计算机信息、通过磁探头设备在Android和iOS设备上获取加密秘钥。相关的报道很多，这里不再一一赘述。

边信道攻击和应用安全

在应用安全领域，时间信道进行攻击（Time attack，又称时序攻击）是一种比较常见的边信道攻击方式。根据应用软件的特性，我们可以构造不同的输入数据来观察程序执行某些流程耗时的差别，通过统计分析的方法来获取我们想要的信息。在现实生活中，张三晚上二十一点打隔壁老王家客厅座机，打10次有8次老王接的比平时慢，那么张三基本可以断定老王晚上睡觉的时间应该早于二十一点，这就是一种时序攻击。

2010年，Sebastian Schinzel在OWASP的一次会议上就做过题为《Side Channel Vulnerabilities on the Web - Detection and Prevention》的报告，里面介绍了一种基于应用程序流程执行差异的时序攻击模型并给出了防御方法。这里顺便多说一句，Sebastian Schinzel的研究领域非常广泛，OpenSSL的DROWN漏洞(水牢漏洞)也是这位国际友人发现并报告给官方的。

在Black Hat 2013大会上，英国安全研究员Paul Stone就做过一个基于时间边信道攻击的报告，他利用基于JavaScript的时序攻击结合其它一些攻击策略，能够从目标用户浏览器上窃取信息。

PHP应用程序中的字符串比较一直是时序攻击的重灾区，在找回密码等应用场景种均有可能存在此类安全隐患。大量知名的PHP开源应用程序都在这里栽倒过，比如piwik就在去年就发过补丁。

这个坑也是源远流长，Ircmaxell对这个问题做过详细的分析。在比较两个字符是否一致的时候，首先PHP会做长度判断。如果字符长度不一样，就不用比下去了，这是一个时序攻击的利用点。

然后，如果长度一样就用memcmp来比较了，这里我大PHP要接C语言的锅了

可以看到这里本质是逐位比较的。我们可以构造如下的序列循环比较，记录下来每次尝试的时间。

如果发现某个字符的时间比较长，基本就可以确定已经命中了这一位。固定住这一位后可以对下一位继续进行猜测。PHP为了解决这个问题，甚至专门提供了相关的安全函数。

网络安全的跨界合作

边信道攻击，作为一种在学术研究领域（特别是密码学领域）广为应用的攻防方式，在工业领域也发出了耀眼的光芒，体现了学术界和工业界在相互借鉴、认可和融合。

在过去的很多年中，国内学术界关于网络安全的研究和教学大多侧重于密码学领域。而在工业领域，大家则更侧重于系统漏洞和攻防实战。学术界和工业界的合作融合，相对比较少，看问题的角度，也有所差别。比如针对某一类攻击方法，从学术价值上看非常具有创新性，但是从工业界看却难有施展的场景，讨论起来的时候一言不合就只能拿酒说话了。

最近几年，情况有了很大的改变。一些有很强学术背景的牛人，在工业领域里取得了令人钦佩的成果，比如盘古团队的王铁磊和PaloAlto的屈波等超级大神。在密码学研究领域非常知名的上海交通大学loccs实验室甚至培养出了夺得过CTF赛事世界冠军的0ops团队。

在2015年底，清华段海新老师、复旦杨珉老师等活跃在网络安全学术和技术圈的研究人员发起了网络安全研究国际学术论坛（简称网安国际，InForSec，www.inforsec.org ）。

若干年后回首网络安全发展史，这可能是一个里程碑式的事件。InForSec通过组织一些活动，极大的促进了学术和工业的了解和交流。TSRC也在积极的为InForSec提供一些力所能及的支持，希望InForSec走的更远走的更好。

在未来的几年中，我们一定能够看到更多类似GeekPwn上边信道劫持TCP通信的精彩技术从学术界走向工业界。学术界发现问题、解决问题的方法能够给工业界的同学更多的启迪和思考，而工业界也能够给学术界提供更为广泛的战场。

本文转载自腾讯安全应急响应中心官方微信公众号（tsrc_team）

个人收藏，侵删。

1. 配置参数

本文是HaP核心的配置文件详解，比如global,defaults之类的能看到的配置语法，都可以在这里找到注释

1.1 global

global在配置文件中，主要设置一些全局性的参数，起重要作用
一般建议不要修改，特别是pid文件地址，如果修改了可能会导致无法正常停止HaP核心

1.1.1 daemon

HaP核心运行方式为：后台运行

1.1.2 user group

user - group
设置HAP核心工作所属的用户和组

• 示例

1
2
3
4
5
6
7
8
9

#设置HAP核心工作的用户和组为:inet
user inet
group inet 

###################################

#设置HAP核心工作的用户和组为:root
user root 
group root

1.1.3 maxconn

设置每个进程可用的最大连接数

• 示例

1
2

#设置每个进程可用的最大连接数20480
maxconn 20480

1.1.4 chroot

改变当前工作目录
一般不需要添加，所以在配置语法中这句是注释掉的，也不推荐使用，因为 pidfile 文件的路径是相对路径，这个会干扰 pidfile 文件的存放地址

• 示例

1
2
3
4
5

#设置工作目录为HaP的私有目录
chroot /data/data/com.HaP.Byml/files

#/data/data/com.HaP.Byml/files目录
#就是HaP的私有目录

1.1.5 pidfile

haproxy的pid存放路径，启动进程的用户必须有权限访问此文件
不推荐修改这个地址，修改以后会干扰自带的HAP停止脚本

• 示例

1
2
3
4
5

#设置pidfile文件地址
pidfile ./haproxy.pid 

#上面的配置会使在配置文件相同的目录下创建pid文件
#及这就是相对目录，建议默认就这样

1.2 defaults

默认的一个模块，一些超时和一些缺省值需要要设置的参数在这个模块设置

1.2.1 timeout connect

超时参数：连接超时
如果一个连接超过了超时参数设置的值没有进行响应操作，就会自动断开连接，返回一个错误的报文

• 示例

1
2

#设置连接超时为：30000ms
timeout connect 30000ms

1.2.2 timeout client

超时参数：客户端超时
如果客户端超过了超时参数设置的值没有进行响应操作，就会自动断开连接，返回一个错误的报文

• 示例

1
2

#设置客户端超时为：300000ms
timeout client 300000ms

1.2.3 timeout server

超时参数：服务器端超时
如果服务器端超过了超时参数设置的值没有进行响应操作，就会自动断开连接，返回一个错误的报文

• 示例

1
2

#设服务器端超时为：3000000ms
timeout server 30000ms

1.2.4 stats

设置HaProxy的状态网页
由于有些模式修改过的请求，会干扰HAP核心的识别状态页面，所以推荐用默认透明模式进行访问状态页面

• 示例

1
2

#设置HaP核心的状态页面为/hap
stats uri /hap

在默认透明模式下访问http://127.0.0.1:监听端口/hap 就可以进入状态网页

1.2.5 option redispatch

serverId对应的服务器挂掉后，强制定向到其他健康的服务器

1.2.6 option abortonclose

当服务器负载很高的时候，自动结束掉当前队列处理比较久的连接

1.2.7 option httpclose

每次请求完毕后主动关闭HTTP通道
老版本的HAProxy不支持keep-alive模式 ，HAProxy会针对客户端的第一条请求的返回添加cookie并返回给客户端，客户端发送后续请求时会发送此cookie到HAProxy，HAProxy会针对此cookie分发到上次处理此请求的服务器上，如果服务器不能忽略此cookie值会影响处理结果。
要避免这种情况可配置此选项，防止产生多余的cookie信息。

1.3 frontend

前端配置，可以在里面进行请求方法过滤和拦截请求操作

1.3.1 mode http

mode { tcp|http|health } 设定启动的实例的协议类型
非对HAP核心了解的用户禁止修改，修改后可能导致无法上网

• 示例

1
2

#设置协议类型为http协议
mode http

1.3.2 option accept-invalid-http-request

允许接受错误的HTTP请求
有些模式修改后，会使得核心识别为错误的请求，导致直接返回一个错误请求，无法上网。要避免，加上此选项就行。

1.3.3 acl http_g/p/s method GET/POST/HTTPS

acl 操作
上面的http_g/p/s会在后面用的，相当于if语句的条件

• 示例

1
2
3
4
5
6
7
8
9
10
11

#判断请求模式是否为GET
acl http_g method GET
#如果为GET http_g就为true

#判断请求模式是否为POST
acl http_p method POST
#如果为GET http_p就为true

#判断请求模式是否为CONNECT(https)
acl http_s method CONNECT
#如果为GET http_s就为true

1.3.4 use_backend http-get/post/https if http_g/p/s

如果acl操作的值为true,

• 示例

1
2
3
4
5
6
7
8

#如果http_g为true就使用http-get模块
use_backend http-get if http_g

#如果http_p为true就使用http-post模块
use_backend http-post if http_p

#如果http_s为true就使用https模块
use_backend https if http_s

1.3.5 default_backend https

默认使用的模块，当请求方法非get/post/https时，就会启用

• 示例

1
2

#设置默认模块为:https
default_backend https

2. 请求处理语法

2.1 中文语法

添加中文语法的主要原因，是英文语法多多少少有些繁琐，不易写模式，而且很多友友都不懂英文语法，甚至看到英文就头疼。
添加中文语法对HaP的效率没有影响，最终的处理的都和英文语法一样。中文语法中的语句，都可以在英文语法里找到相同的作用的语法。
HaP是一款免费的软件，希望大家能尽量分享一些，多帮助些新人，这样才能发展HaP。

2.1.1 添加一行

在请求中添加一行请求

• 原型
  请求 添加一行 hanme value

• 参数

  • 参数1：hname 必填，一行的行头名称
  • 参数2：value 必填，一行的值，支持%[xxx]操作

• 示例

1
2

#在请求中添加一行：test: abc\r\n 
请求 添加一行 test abc

2.1.2 设置行值

设置一行的值

• 原型
  请求 设置行值 sanme value

• 参数

  • 参数1：sname 必填，需要设置的值得行名称
  • 参数2：value 必填，一行的值 ，支持%[xxx]操作

在请求中，寻找sname行，如果存在就修改sname行的值，如果不存在就在请求结尾添加sname行，值为value

• 示例

1
2

#设置Host行的值为:10.0.0.172
请求 设置行值 Host 10.0.0.172

2.1.3 设置行值2

设置一行的值（与设置行值一致）

• 原型
  请求 设置行值2 sanme value

• 参数

  • 参数1：sname 必填，需要设置的值得行名称
  • 参数2：value 必填，一行的值 ，支持%[xxx]操作

在请求中，寻找sname行，如果存在就修改sname行的值，如果不存在就在请求结尾添加sname行，值为value

• 示例

1
2

#设置Host行的值为:10.0.0.172
请求 设置行值2 Host 10.0.0.172

2.1.4 删除一行

删除请求中的一行

• 原型
  请求 删除一行 danme

• 参数

  • 参数1：dname 必填，需要删除的行名称

会删除请求中的dname行

• 示例

1
2

#删除请求中的Host行
请求 删除一行 Host

2.1.5 删除一行2

删除请求中的一行（与删除一行一致）

• 原型
  请求 删除一行2 danme

• 参数

  • 参数1：dname 必填，需要删除的行名称

会删除请求中的dname行

• 示例

1
2

#删除请求中的Host行
请求 删除一行2 Host

2.1.6 替换字符串

替换请求中指定的字符串

• 原型
  请求 替换字符串 str1 str2

• 参数

  • 参数1：str1 必填，需要被替换的字符串，支持%[xxx]操作
  • 参数2：str2 必填 ，需要替换的字符串

在请求中，把str1字符串替换为str2字符串

• 示例

1
2
3
4
5

#修改HTTP协议版本为:1.0
请求 替换字符串 HTTP/1.1 HTTP/1.0

#把Host行替换成X-Online-Host行
请求 替换字符串 \nHost: \nX-Online-Host:

2.1.7 之前添加

在请求中某一个字符串前面添加字符串

• 原型
  请求 之前添加 name str

• 参数

  • 参数1：name 必填，确定在哪一个字符串前面添加字符串
  • 参数2：str 必填，需要添加的字符串，支持%[xxx]操作

在请求中的的name字符串前添加str字符串

• 示例

1
2

#在Host行前面添加一行：test,值为abc
请求 之前添加 Host: test:\ abc\r\n

2.1.8 之后添加

在请求中指定字符串后面添加字符串

• 原型
  请求 之后添加 name str

• 参数

  • 参数1：name 必填，确定在哪个字符串后面添加字符串
  • 参数2：str 必填，需要添加的字符串，支持%[xxx]操作

在请求中的name行后面添加str字符串

• 示例

1
2

#在首行下面添新的一行test 值为abc
请求 之后添加 \n test:\ abc\r\n

2.1.9 行前添加

在请求中某一行前面添加字符串

• 原型
  请求 行前添加 name str

• 参数

  • 参数1：name 必填，确定在哪一行前面添加字符串
  • 参数2：str 必填，需要添加的字符串，支持%[xxx]操作

在请求中的的name行前添加str字符串

• 示例

1
2

#在Host行前面添加一行：test,值为abc
请求 行前添加 Host test:\ abc\r\n

2.1.10 行后添加

在请求中某一行后面添加字符串

• 原型
  请求 行后添加 name str

• 参数

  • 参数1：name 必填，确定在哪一行后面添加字符串
  • 参数2：str 必填，需要添加的字符串，支持%[xxx]操作

在请求中的的name行后面添加str字符串

• 示例

1
2

#在Host行后面添加一行：test,值为abc
请求 行后添加 Host test:\ abc\r\n

2.1.11 行值前添加

在一行值的前面添加字符串

• 原型
  请求 行值前添加 name str

• 参数

  • 参数1：name 必填，确定在哪一行值的前面添加字符串
  • 参数2：str 必填，需要添加的字符串，支持%[xxx]操作

在请求中的的name的值前面添加添加str字符串

• 示例

1
2
3
4
5

#在Host行值前面添加字符串：abc
请求 行值前添加 Host abc
#如果Host行整行为:Host: wap.baidu.com\r\n
#那么使用上面的Host行就会变成：Host:abcwap.baidu.com\r\n
#这个时候Host行值的前面增加了abc，这就是'行值前添加'语法的作用

2.1.12 行值后添加

• 原型
  请求 行值后添加 name str

• 参数

  • 参数1：name 必填，确定在哪一行值的后面
  • 参数2：str 必填，需要添加的字符串，支持%[xxx]操作

• 示例

1
2
3
4
5

#在Host行值后面添加abc
请求 行值后添加 Host abc
#如果Host行的整行为:Host: wap.baidu.com\r\n
#使用上面的语法后Host整行为：Host: wap.baidu.comabc\r\n
#这个时候Host行值后面添加了abc，这就是'行值后添加'语法的作用

2.1.13 URL前添加

• 原型
  请求 URL前添加 str

• 参数

  • 参数1：str 必填，需要添加的字符串，支持%[xxx]操作

• 示例

1
2

#在请求URL之前添加字符串str
请求 URL前添加 str

2.1.14 URL后添加

• 原型
  请求 URL后添加 str

• 参数

  • 参数1：str 必填，需要添加的字符串，支持%[xxx]操作

• 示例

1
2

##在请求URL之后添加字符串str
请求 URL后添加 str

2.1.15 删除网址http://host

• 原型
  请求 删除网址http://host null null

• 参数

  • 参数1： 可选，默认null即可
  • 参数2： 可选，默认null即可

在请求的第一行通常是这样的
GET(method) http://wap.baidu.com/?from=xxx
由于某些特殊修改请求的方法，需要去掉请求中的http://wap.baidu.com
所以出现了上面的语法，语法跟mov-fhttp null null作用一样

• 示例

1
2

#删除网址http://host
请求 删除网址http://host null null

2.1.16 删除s_e

• 原型
  请求 删除s_e start end

• 参数

  • 参数1：start 必填,开始字符
  • 参数2：end 必填，结束字，支持%[xxx]操作符

删除start到end之间的字符，保留end

• 示例

1
2
3

#删除网址http://host
请求 删除s_e http:// /
#上面的语句的作用就等于删除网址http://

2.1.17 删除s_e2

• 原型
  请求 删除s_e2 start end

• 参数

  • 参数1：start 必填，开始的字符
  • 参数2：end 结束的字符串，支持%[xxx]操作

删除start到end的字符，删除end，跟删除s_e的区别就是s_e保留了end,这个语法删除了end

• 示例

1
2
3

#删除Host行
请求 删除s_e2 Host \r\n
#上面的语法的意思是删除：以Host开头到以\r\n结尾的字符串，开头和结尾都删除

2.1.18 atob a b

主要用于转换行头（行头就是一行的名字，通常有host行的叫法，就是因为行头为Host）
如果a行存在，那么行头就替换成b行，b行不管存不存在都会被删除
如果a行的值为空，那么a行将会被删除，b行保留

• 原型
  请求 atob a b

• 参数

  • 参数1：a 必填，A行
  • 参数2：b 必填，B行

• 示例

1
2

#X-Online-Host转Host
请求 atob X-Online-Host Host

2.1.19 设置第一行 str

自定义请求的第一行

• 原型
  请求 设置第一行 str

• 参数

  • 参数1：str 必填，支持%[xxx]操作

• 示例

1
2
3
4

#具体事例 http://host转http://proxy_host
请求 设置第一行 %[method]\ http://prxoy_host%[request_uri]\ HTTP/1.1\r\n
#%[method] 请求方法 GET/POST/CONNECT
#%[request_uri] 请求url 跟php的REQUEST_URI类似

2.1.20 设置行名 hdrA hdrB

设置一行请求的行名

• 原型
  请求 设置行名 hdrA hdrB

• 参数

  • 参数1：`hdrA 需要被改名的请求行必填
  • 参数1： 将要改为的行名

• 示例

1
2
3

#Host行改为T_Host行
请求 设置行名 Host T_Host
#就把Host行的行名：Host改为了T_Host

2.2 英语语法

这里语法的作用都是同上面中文语法的
英文语法在后来的版本中对原来的语法进行优化和修复
在1.5版本后,set-header/2,del-header/2全部为自定义语法
这样做的目的是为了稳定性和安全性考虑

2.2.1 add-header

添加一行

• 原型
  http-request add-header h v

• 参数

  • h： 必填，需要添加的行
  • v： 必填，需要添加行的值，支持%[xxx]操作

添加新的一行，行头为h，值为v

• 示例

1
2

#添加test行，值为abc
http-request add-header test abc

2.2.2 set-header

设置一行的值

• 原型
  http-request set-header h v

• 参数

• h： 必填，需要修改值的行
• v： 必填，需要修改的值，支持%[xxx]操作

设置h行的值为v，不会修改位置

2.2.3 set-header2

设置一行的值

• 原型
  http-request set-header2 h v

• 参数

  • h： 必填，需要修改值的行
  • v： 必填，需要修改的值，支持%[xxx]操作

• 示例

1
2

#设置Host行的值为10.0.0.172
http-request set-header2 Host 10.0.0.172

2.2.4 del-header
删除请求中的一行

• 原型
  http-request del-header h

• 参数

  • h： 必填，被删除的行头

删除请求中的h行

• 示例

1
2

#删除请求中的Host行
http-request del-header Host

2.2.5 del-header2

删除请求中的一行，与del-heder语法的区别就是此语法更稳当，del-header语法为开发语法

• 原型
  http-request del-header2 h

• 参数

  • h： 必填，被删除的行头

• 示例

1
2

#删除请求中Host行
http-request del-header2 Host

2.2.6 add-replace(str_repalce)

替换请求中的字符串

• 原型
  http-request add-replace(str_replace) str1 str2

• 参数

  • str1： 必填，被替换的字符串，支持%[xxx]操作
  • str2： 必填，替换的字符串

把请求中的str1字符串替换成str2字符串

示例

1
2

#更改http协议版本为1.0
http-request add-replace HTTP/1.1 HTTP/1.0

2.2.7 add-before

在指定字符串前面添加字符串

• 原型
  http-request add-before name str

• 参数

  • name： 必填，定位在哪个字符串前面添加字符串
  • str： 必填，需要添加的字符串 ，支持%[xxx]操作

• 示例

1
2

#Host行前添加一行test,值为abc
http-request add-before Host test:\ abc\r\n

2.2.8 add-after

在指定字符串后面添加字符串

• 原型
  http-request add-after name str

• 参数

  • name： 必填，定位在哪个字符后面添加字符
  • str： 必填，要添加的字符，支持%[xxx]操作

• 示例

1
2

#在首行下面添加一个Host 值为test
http-rrequest add-after \n Host:\ test\r\n

2.2.9 add-lbefore

在指定行之前添加字符串

• 原型
  http-request add-lbefore h str

• 参数

  • h： 必填，在指定的行前
  • str： 必填， 添加的字符串，支持%[xxx]操作

• 示例

1
2

#在Host行前添加新的一行test值为abc
http-request add-lbeofore Host test:\ abc\r\n

2.2.10 add-lafter

在指定行后添加字符串

• 原型
  http-request add-lafter h str

• 参数

  • h： 必填，在指定的行后
  • str： 必填， 添加的字符串，支持%[xxx]操作

• 示例

1
2

#在Host行后添加新的一行:test行值为：abv
http-request add-lafter Host test:\ abc\r\n

2.2.11 add-vbefore

在指定行后的值前面添加字符串

• 原型
  http-request add-vbefore h v

• 参数

  • h： 必填，确定在哪一行值的前面添加字符串
  • v： 必填，添加的字符串 ，支持%[xxx]操作

在h行的值后面添加字符串v

• 示例

1
2
3
4
5

#在Host行值前面添加字符串：abc
http-request add-vbefore Host abc
#如果Host行整行为:Host: wap.baidu.com\r\n
#那么使用上面的Host行就会变成：Host:abcwap.baidu.com\r\n
#这个时候Host行值的前面增加了abc，这就是'add-hbefore'法的作用

2.2.12 add-vafter

在指定行的值后面添加

• 原型
  http-request add-vafter h v

• 参数

  • h： 指定哪个行值后面添加字符串
  • v： 需要添加的字符串，支持%[xxx]操作

• 示例

1
2
3
4
5

#在Host行值后面添加abc
http-request add-vafter Host abc
#如果Host行的整行为:Host: wap.baidu.com\r\n
#使用上面的语法后Host整行为：Host: wap.baidu.comabc\r\n
#这个时候Host行值后面添加了abc

2.2.13 add-ubfore

在请求URL前面添加字符串

• 原型
  http-request add-ubefore str

• 参数

  • str： 添加的字符串，支持%[xxx]操作

• 示例

1
2

#在请求url前添加'http://bml.net'
http-request ubefore http://byml.net

2.2.14 add-uafter

在请求URL之后添加字符串

• 原型
  http-request add-uafter str

• 参数

  • str： 添加的字符串，支持%[xxx]操作

• 示例

1
2

#在请求URL后面添加字符串?abc
http-request add-uafter ?abc

2.2.15 atob a b

a行转b行

• 原型
  http-request atob a b

• 参数

  • a： a行
  • b： b行

如果a行存在，b行存在，则会把b行删除，把a行的行头改成b
如果a行的值为空，则会删除a行，保留b行
如果a行不存在，则不会做任何处理

• 示例

1
2

#X-Online-Host转Host
http-request atob X-Online-Host Host

####2.2.16 rep-hvalue
修改一行的值，如果不存在行就不添加

• 原型
  http-request rep-hvalue h v

• 参数

  • h： 修改值的行
  • v： 需要修改成的值，支持%[xxx]操作

• 示例

1
2

#修改host行的值为byml.net，如果不存在则不做任何处理
http-request rep-havlue Host byml.net

2.2.17 mov-fhttp

删除请求网址开头：http://host

• 原型
  http-request mov-fhttp null null

• 参数

  • null： 默认即可
  • null： 默认即可，支持%[xxx]操作

• 示例

1
2

#使用例子
http-request mov-fhttp null null

2.2.18 mov-se s e

删除以s开头到e结尾的字符串，保留e

• 原型
  http-request mov-se s e

• 参数

  • s： 开始的字符串
  • e： 结束的字符串，支持%[xxx]操作

• 示例

1
2

#删除请求地址中的http://host
http-request mov-se http:// /

2.2.19 mov-nse s e

删除以s开头到e结尾的字符串，删除e

• 原型
  http-request mov-nse s e

• 参数

  • s： 开始的字符串
  • e： 结束的字符串，支持%[xxx]操作

• 示例

1
2
3

#删除Host行
http-request mov-nse Host \r\n
#一行的结束标志是\r\n

2.2.20 set-req-fline str

自定义请求的第一行

• 原型
  http-request set-req-fline str

• 参数

  • str： 支持%[xxx]操作

• 示例

1
2
3
4

#http://host转http://proxy_host
http-request set-req-fline %[method]\ http://proxy_host%[request_uri]\ HTTP/1.1\r\n 
#%[method] 请求方法 GET/POST/CONNECT
#%[request_uri] 请求的url 跟php的REQUEST_URI类似

2.2.21 rn-header hdrA hdrB

设置一行请求的行名

• 原型
  http-request rn-header hdrA hdrB

• 参数

  • hdrA： 被改名的请求行
  • hdrB： 需要改为的名称

• 示例

1
2
3

#Host行改为T_Host
http-request rn-header Host T_Host
#把Host行的请求名：Host 改为了T_Host

2.2.22 xhostTot

Xhost,Host（如果没有大写的，则自动查找小写）转换为T_Host
如果xhost,host均存在
则以xhost优先，把xhost请求行名改为T_Host
如果host行存在，xhost不存在
则以host行优先，把host行改为T_Host行

• 原型
  http-request xhostTot null null

• 参数

  • null： 无作用，但必须加
  • null： 无作用，但必须加

• 示例

1

http-request xhostTot null null

3.特殊用法

3.1 %[xxx]操作

%[xxx]操作就相当于变量，到了核心就会被转换成这个变量存储的数据

3.1.0 %[header(xxxx)]

例如：%[header(Host)]
就是取：Host行的值
这个语法为新增加语法，更适合编写模式

3.1.1 %[url]

如果请求的第一行为：GET http://byml.net/index.php HTTP/1.1\r\n
那么%[url]代表的是http://byml.net/index.php

3.1.2 %[request_uri]

如果请求的第一行为：GET http://byml.net/index.php?user=recall HTTP/1.1\r\n
那么%[request_uri]代表的是：/index.php?user=recall

3.1.3 %[req.hdr(xxx)]

例如：%[req.hdr(Accept)]
就是取Accept行的值

如果是要取Host的值
推荐使用%[host]，这个是固定的，不会出现取值失败，自动停止等BUG

3.1.4 %[method]

如果当前的请求方式为GET
那么%[method]的值就是GET

3.1.5 %[req.ver]

req.ver是当前使用的HTTP协议的版本
如果请求是HTTP/1.1 %[req.ver]则为1.1
如果请求是HTTP/1.0 %[req.ver]则为1.0

3.1.6 %[url_no_port]

如果CONNECT请求的第一行为CONNECT byml.net:443 HTTP/1.1\r\n
那么%[url_no_port]代表byml.net，目前只推荐在CONNECT请求中使用

3.1.7 %[host]

取Host行的值，解决atob后，%[req.hdr(Host)]取不到值的BUG

3.1.8 %[t_host]

取T_Host行的值，可以先把Host字符串修改成T_Host
这样就可以直接%[t_host]取到Host的值，而且只需要定义第一行就行了

3.1.9 %[xhost]

取X-Online-Host行的值，固定搭配

3.2 核心函数

3.2.1 未完待续

一张图说明一切：

倘若你是个脑力劳动者，做的工作无定规可循，不能简单重复，需要不断激荡脑力、解决问题、生产灵感、执行创意……很可能你会发现，自己的工作状态分为两种。

• 一是虚掷模式。无人打扰，时间大段，身体康健睡眠充足，咖啡零食一应俱全，双显示器机械键盘，网络通畅电脑正常……然后？你摸鱼打混，聊天追文，悠然不觉长日将逝。
• 二是救火模式。没有一点点防备，一条死线就猝然“砰”一声砸到眼前。我怎么把这事忘得一干二净？你一边恼火，一边突然发现，不论环境如何，处处皆可工作。网络有如龟速？先读现有资料。电脑出了故障？手机打字足矣。夜半可以加班，车上可以路演，嘈杂周遭，也不能令你分心丝毫……咬牙冲过截止线，你终于长松口气，要是平常有这效率，怎需如今这般累个贼死？

仍有余裕时不能自制，突发意外时，不得不透支未来资源来救急，而这种透支又让明天比今天更难捱，结果每天为着早该完成的事宜疲于奔命，一天比一天更难以自拔——一旦陷入这种“虚掷-救火”的循环陷阱，待办事项就往往越积越多，就像欠了高额债务的人，发现偿付欠款甚至利息越来越难。美国心理学家塞德希尔·穆来纳森（Sendhil Mullainathan）和埃尔德·沙菲尔（Eldar Shafir）共同撰写的《稀缺》一书解释说，在资源富足时，大脑固然会掉以轻心。在资源极度缺乏时，大脑却也不能做出明智抉择，反而会孤注一掷，饮鸩止渴。

怎么解决？ 让大脑在“可控的稀缺”下工作。 更具体地说，不妨先把你计划中的工作时间大幅缩减，譬方说，将每天的计划内工作，严格限于三小时之内——别小看三小时，坐办公室的美国人，平均一天真正工作的时间大概才90分钟。

“决心做得更少”，却能帮你“实际做得更多”——只因你一开始梦想的“每周五天，每天八小时，始终保持死线来临前的高效”，根本是不可能做到的！未经严苛训练的大脑，不可能每天高效工作七小时。即使迫于极端压力而做到，也往往要付出透支的代价——透支其他未来项目的时间，透支自己的意志力，透支睡眠质量，乃至透支身心健康。救火模式正是如此。而内疚，自责，压力，焦虑，睡眠缺乏，没空休假，无暇与亲友相聚减压……救火时相伴而来的这些副产品，就像跑步时的额外负重，让你挣扎前行时，更加疲惫不堪。

想象如下场景，运动零基础的你决心开始慢跑，教练给了你这么一张健身计划：“每周跑五天，每天早上八点跑到中午十二点，休两小时，下午两点跑到六点，喔对了，记得负重十公斤。”

你的第一反应肯定是，这怎么可能！我根本跑不下来，估计十分钟后我就会在地上摊成一张肉饼。即使我拿出被狮子追时的意志力跑完一天，此后肯定也得卧床休息，没准还是在医院住院部卧床休息。

正常人不会给自己定这种健身计划，然而，年复一年，人们却给自己定这种工作计划。

最常见的错误，是计划时无余闲，将日程塞得满满当当，执行时则“弹性十足”——大脑一边因虚幻的“今日有八小时可供（高效）工作”而安于低效，一边还随时准备删改计划，扑去救火。

你需要做的，是 计划时有余闲，执行时无弹性 。是说服大脑“今天只有三小时可以工作”，让大脑悚然一惊，抖擞精神，像救火时那样目标明确，执行坚决。而日程表上留出的大量“余闲”，实际上是给你处理那些必然会出现的“突发状况”。如此，你就不至于因为各种“天降任务”而一次次推迟原定计划，导致最后主线任务反而挫折不断，难以进展。一个无法执行的计划，等于没有计划。而一个真正可执行的好计划，则一定会让你更高效。

原文链接：http://songshuhui.net/archives/93667

内容目录

在段落中填写 [TOC] 以显示全文内容的目录结构。

文章头格式

front-matter 的基本格式示例如下：

1
2
3
4
5
6
7
8

---
title: Hexo Markdown-it 简明语法手册
date: 2016-01-15 20:19:32
tags: [Markdown,LaTex,教程]
categories: 学习
toc: true
mathjax: true
---

斜体和粗体

使用 * 和 ** 表示斜体和粗体，格式如下：

1

*斜体*， **粗体**

渲染效果： 这是 斜体，这是 粗体 。

分级标题

使用 === 表示一级标题，使用 --- 表示二级标题，格式如下：

1
2
3
4
5
6
7

这是一个一级标题
============================

这是一个二级标题
--------------------------------------------------

### 这是一个三级标题

你也可以选择在行首加#号表示不同级别的标题 (H1-H6)，格式如下：

1
2
3
4
5
6

# H1
## H2
### H3
#### H4
##### H5
###### H6

分割线

在单独的一行使用 *** 或者 --- 表示分割线

删除线

使用 ~~ 表示删除线
这是一段错误的文本。

超链接

插入文字超链接的格式如下 ：

1

[链接文字](链接地址 "链接标题")

插入图片超链接的格式如下：

1

![图片说明](图片链接 "图片标题")

插入音频，使用插件hexo-tag-aplayer，语法如下：

1

{% aplayer title author url [picture_url, narrow, autoplay, width:xx%, lrc:xxx] %}

详情参见：hexo-tag-aplayer 中文使用文档

引用视频则直接插入iframe代码：

1
2

<script src="/js/youtube-autoresizer.js"></script>
<iframe width="640" height="360" src="https://www.youtube.com/embed/HfElOZSEqn4" frameborder="0" allowfullscreen></iframe>

文字：本博客链接

图片：

视频：

注释

用 \ 表示注释，\ 后面的文字解析为纯文本格式。
渲染效果：
## 这不是二级标题

引用

使用 > 表示文字引用：

1

> 野火烧不尽，春风吹又生

野火烧不尽，春风吹又生

脚注

使用 [^1] [^1]: 的脚注对来表示

1
2
3
4
5
6
7

Here is a footnote reference,[^1] and another.[^longnote]

[^1]: Here is the footnote.

[^longnote]: Here's one with multiple blocks.
    Subsequent paragraphs are indented to show that they
    belong to the previous footnote.

Here is a footnote reference,^[1] and another.^[2]

列表与表格

无序列表

使用 *，+，- 表示无序列表。

1
2
3
4
5
6

+ 无序列表项 一
- 子无序列表 一
- 子无序列表 二
* 子无序列表 三
+ 无序列表项 二
+ 无序列表项 三

• 无序列表项 一
  • 子无序列表 一
  • 子无序列表 二
    • 子无序列表 三
• 无序列表项 二
• 无序列表项 三

有序列表

使用数字和点表示有序列表。

1
2
3
4
5

1. 有序列表项 一
1. 子有序列表项 一
2. 子有序列表项 二
2. 有序列表项 二
3. 有序列表项 三

1. 有序列表项 一
   1. 子有序列表项 一
   2. 子有序列表项 二
2. 有序列表项 二
3. 有序列表项 三

绘制表格

绘制表格格式如下，| 控制分列，- 控制分行，: 控制对齐方式。

1
2
3
4
5

| Item     | Value     | Qty   |
| :------- | --------: | :---: |
| Computer | 1600 USD  | 5     |
| Phone    | 12 USD    | 12    |
| Pipe     | 1 USD     | 234   |

代码块

行内代码块

使用 `codes` 表示行内代码块。

渲染效果： 让我们聊聊 html 。

多行代码块

1
2
3

这是用 ``` some codes ```表示的代码块（左侧无空格）；
第二行；
第三行。

加强的代码块

支持多种编程语言的语法高亮的显示，行号显示。

非代码示例：

1

$ sudo apt-get install vim-gnome

Python 示例：

1
2
3
4
5
6
7
8
9
10
11
12

requires_authorization
def somefunc(param1='', param2=0):
    '''A docstring'''
    if param1 > param2: # interesting
        print 'Greater'
    return (param2 - param1 + 1) or None

class SomeClass:
    pass

>>> message = '''interpreter
... prompt'''

JavaScript 示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/*
* nth element in the fibonacci series.
* @param n >= 0
* @return the nth element, >= 0.
*/
function fib(n) {
  var a = 1, b = 1;
  var tmp;
  while (--n >= 0) {
    tmp = a;
    a += b;
    b = tmp;
  }
  return a;
}

document.write(fib(10));

LaTeX 公式

数学公式的默认定界符是$...$和\\(...\\)（对于行内公式），以及$$...$$和\\[...\\]（对于块级公式）。
但是，如果你的文章内容中经常出现美元符号$,或者说你想将“$”用作美元符号而非行内公式的定界符，请在Hexo目录的_config.yml中添加：

1

mathjax2: true

而不是mathjax: true。 相应地，在需要使用数学公式的文章的front-matter中也添加mathjax2: true。

例如：

质能守恒方程: $E = mc^2$: $E = mc^2$

长度收缩：$x' = {x - vt \over \sqrt{1 - {v^2 \over c^2}}}$: $x’ = {x - vt \over \sqrt{1 - {v^2 \over c^2}}}$

表示块级公式：

1

$$\Delta_A(\lambda)=\det(\lambda I-A)$$

$$\Delta_A(\lambda)=\det(\lambda I-A)$$

或者：

1
2
3

\begin{equation}
\Delta_A(\lambda)=\det(\lambda I-A),
\end{equation}

\begin{equation}
\Delta_A(\lambda)=\det(\lambda I-A),
\end{equation}

1
2
3
4
5

\begin{aligned}
\dot{x} & = \sigma(y-x) \\\
\dot{y} & = \rho x - y - xz \\\
\dot{z} & = -\beta z + xy
\end{aligned}

（此处需注意换行符转义，多加一个\）

\begin{aligned}
\dot{x} & = \sigma(y-x) \
\dot{y} & = \rho x - y - xz \
\dot{z} & = -\beta z + xy
\end{aligned}

1
2
3
4
5
6
7
8
9

\begin{equation}
[a, b, c]=\left|
\begin{array}{ccc}
  a_1& a_2  & a_3  \\\
 b_1 &b_2   & b_3  \\\
 c_1 &c_2   &c_3   
\end{array}
\right|
\end{equation}

\begin{equation}
[a, b, c]=\left|
\begin{array}{ccc}
a_1& a_2 & a_3 \
b_1 &b_2 & b_3 \
c_1 &c_2 &c_3
\end{array}
\right|
\end{equation}

访问 MathJax basic tutorial and quick reference 参考更多使用方法。

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment