分类：未分类

开个 swift 的系列贴先。

自己的活，经常做到只差一口气了，却对这个活产生了抵触情绪，就是不想做，十分抵触，严重时甚至能激起生理上恶心想吐的感觉。

最开始观察到这种症状是在研究生时代，我虽然非常想搞好研究报答教授，但真的是无论如何都无法开始阅读论文，也不能进行任何和自己的研究课题有关的活动。即使我痛苦的流泪，在地上打滚，却依然不能让身体和大脑按自己的心愿行动。所以我的研究生时代非常的痛苦。

第二次被这个症状伤到，是我加入了大学的游戏社团，担当了其中一个游戏项目唯一的游戏程序员时，在开发的最后阶段，我突然陷入了这种不愿意工作一心想逃避的状态，也是非常的恶劣。结果我害得这个游戏项目拖了5年没有完成。现在主创成员硕士都已经毕业了，我感觉非常的内疚，但依然无法驱动自己去为此工作。

我可以自豪的说，在我专注时，我的学习效率和工作效率都是业界顶级的。但我不得不面对的是事实，能否进入专注状态并不能由我的主观决定。

至今为止，我都借助兴趣带来的专注力来学习和行动。这种借力方式帮助我取得了相当高的成就。但帆船总不能逆风而行。在我的兴趣消失的时候，那种超人般的能力和天赋也会随之消失。

我曾经尝试过压抑兴趣消失时的抵抗状态，强行执行高强度的学习计划——每天背单词12小时以上，结果只坚持了两周，计划就彻底崩溃了，而且之后再也没能重启那个背单词计划。

为了找到适用于我的解除抵抗状态的方法，我回忆了一下过去的几个成功案例。

首先是备考留学考试。当时是每天泡在自习室里看书做题，生活单调但有规律。一旦生活进入规律，那做事就比较容易坚持了。

之后印象比较深的成功案例是硕士毕业论文。当时是截稿日前一天，我连写了31小时的论文，在截稿时间前40分钟提交了我的毕业论文。当时是拖延症遇到截止日期时的效率大爆发状态，所以情况有点不一样。不过仔细回忆一下，我记得当时写论文时头脑进入了一种麻木的状态。可能是熬夜太疲倦了，我平时每分钟会出现3次的各种分心的念头在当时完全没有出现。但这种麻木又不同于完全的大脑疲倦，因为我调用专业知识时完全不受阻碍，思维运转速度正常，只有在分心这方面的活跃程度大幅度下降了。这个可能是拖延遇到截止日期时的特殊反应，不适用于解决平日兴趣消失后的抵触状态。

学生生涯结束以后，我好像就再也没有成功的让自己进入某种规律的枯燥事务中去。不过等等，我其实并不觉得写程序是一件枯燥的事啊，这个抵抗情绪的原因应该不是枯燥这么简单。它似乎没有什么特别的理由，就是有一天，我突然变得很抵触做某件工作，总是很想逃避。
想解决这个问题，我需要一种压抑自己想逃避的心情的能力，或者说方法，某种思考工具。

对这个问题最常见的讨论就是”自控力”了。我也读过几本自控力方面的书，也看了《少有人走的路》，不过想让我开始行动，只是读几本书还是远远不够的。开始行动需要某种契机，要等到某件事激起了我的3分钟热血，然后赶紧趁着这三分钟热血做一个决定，最好是当场就执行了这个决定的一部分，然后一个行动才有可能随之开始。依赖性太强也好自控力太差也好，这就是现在的我。最好的药是最对症的药，而不是理论上最站得住脚的药，道理说再多也无益，要看疗效。

目标太大，需要学习的基础知识太多，所以分而治之，开了很多不同的系列。

这次重学Unity是为了给Moba系列写客户端用的。

Unity在我的工作领域中也是非常有价值的技能。估计今后的手游开发就是Unity领军，没cocos2dx什么事了。好可惜最初猜错了方向，不过也没真正投入什么，不过是几个练手用的个人项目而已。

回顾一下开各种系列的因果关系，应该是：

 

想研究网络协议 (L2tp系列)

|- 先练习一下网络编程 （Http服务器系列也算是网络编程练习了，不过要用在工作里，所以不公开了）

    |- 先做个Moba网游服务器端的实现，练练手 （Moba系列）

        |- 需要有个客户端，用来调试和服务器端的通信 （Unity系列）

 

刚入社的时候有个Unity研修，其实也学了点。不过当时赶时间，就决定做个2D游戏，也只看了2D编程的部分。

这次的Moba是3D的，所以要重新学3D部分。

从头学一个大分类的话，比起网上零散的教程，我更倾向于看书，更有效率，进度更可控。

这次在亚马逊的kindle商店下了很多教程的试读，最后选了一本交怎么用外部导入的asset的书，里面还捎带手讲了一下怎么做游戏和怎么用Photon做Unity的服务器端！找到这么对口的书，也真是奇遇。

顺便一提，现在国内的亚马逊上的书还是很少有kindle版。日本是10本书里9本有kindle版的话，国内就是10本里只有1本有kindle的比例，甚至更低。

我真的是受地理位置限制，没法看纸质版，有些时候只好去淘宝找人做pdf电子版。但是新书一般没有pdf版，而Unity啊cocos2dx这种版本更新频繁且剧烈的工具，对教程的时效性要求很高。反正最后我买的那本书是日文版的。嘛，配那么多图的技术类书籍，中日英我都ok啦= =。

这次的兴趣点在服务器端，客户端作为调试服务器端的工具，凑活凑活就可以。不过我毕竟没有3D编程经验，这个凑活的难度还是未知，搞不好是隐藏boss呢。

 

// 下面写着写着，突然发现应该同时实现客户端和服务器端，因为逻辑都要以服务器端为主的。所以回来写个注释。应该双线去开发这个原型。

 

【客户端】 有限地图和可移动的英雄角色

『服务器端』 对应的数据管理

『服务器端』 收到角色移动命令后，向所有人发送移动消息

【客户端】 右键发送移动消息。接收到移动命令后移动（应该预测移动？）

【客户端】 小兵，可接收移动命令，强制移动命令（弥补预测错误），血量控制命令，生死控制命令

『服务器端』 小兵的逻辑，接收命令和广播命令

…

 

通信方面准备多向lol学习一下。这里先记录一个相关内容的博客，以后用到了再检索。

https://nelsonslog.wordpress.com/2014/08/07/league-of-legends-game-protocol/

最近搞了很多简易HTTP服务器端，参考了各种代码。

今天在参考nanohttpd写我自己的java版HTTP服务器时，发现nanohttpd的示例程序发出的response接收起来很慢。

研究了一下代码，貌似是因为nanohttpd最近刚刚merge了一个别人写的gzip格式输出的pull request，但没有好好检查，导致返回Content-Encoding是gzip的response时，既没有添加Content-Length，又没有使用chunked Transfer-Encoding，这再加上keep-alive，根本就是断了浏览器感知response长度的一切手段，难怪chrome收他的response这么慢，人家只能傻傻的等你服务器端超时关闭连接了啊。

添加一行代码，在gzip输出时启用chunked格式，响应时间立刻从5s降到37ms。我看这次改动简洁易懂，有实践证据，也有理论支撑，把握挺大的，就鼓起勇气发出了我个人账户的第一个pull request。

这次虽然是第一次用私人账户发pull request，但其实我们公司管理代码就是用github，我在公司里常常要发pull request，所以也没什么新鲜感了。

听说有拖延症的人怕自己完不成任务，所以尽量少接任务，结果完成效率还是不尽如人意。

结构化拖延理论认为，有拖延倾向就更应该多接任务，这样为了逃避任务A而去做任务B，不知不觉就能搞定大部分工作了。

所以我要挖新坑，哼哼。

最近在看很多通信协议的东西，也需要看Unix网络编程。但网络编程这东西，没有个具体的需求的话，我也不知道这么些函数，这些模型都适合什么场景。

为了给自己一个练手的空间，这次准备尝试一下对实时网络通信质量要求非常高的领域——MOBA类游戏。

以往做的游戏都是websocket就能搞定的小玩意儿，一点儿也感觉不到各种网络通信方式之间的性能差别。MOBA类游戏有一个最重要也最容易分辨的质量标准，就是延迟。UDP到底比TCP快多少？怎么能在保证快速响应和在有丢包风险的连接上保证逻辑正确呢？还是实践出真理吧。

学L2tp，要先看PPP，直接看PPP的rfc担心直接看陌生领域的英文文献会晕，所以先找了本网络协议分析的中文教材看了起来。

可这个教材也不是直接教完整的PPP的，只是讲了几页纸，后面就是简介各种协议，稍微详细地讲了TCP/IP。

我想L2tp也是要为上层的IP协议服务的嘛，先看看IP协议总没有坏处。可这些协议哪个都是充满了细节，一起看下来需要相当的时间。

这种一直读纯理论，不能上机实验的学习方法，在大学时代就被验证了是很容易磨灭学习热情的。上次两天20小时读完HTTP协议已经是我的忍耐极限了，读完之后我一口气写了一星期的代码才缓过劲来。

这次的vpn项目难度不小，要做好持久战的准备，不能期待像HTTP一样一口气吃下来。那怎么打持久战呢？就是注意回复能力。用LOL的话讲就是要有回血赖线的能力。

读教材看文档，吸收纯理论知识是混线涨经验，但是会消耗精神力，相当于对线期的损血。那写代码加深理解，稳固住刚刚吸收进来，根基还不牢靠的知识，让我不用每时每刻消耗大量精神力去把他们暂存在脑内存中，就是磕血瓶回血了。

目前我经验涨了一些，但是血线有点低了，现在不能贪线上兵，要先稳一稳，猥琐塔下回回血吧。

好，那接下来的目标就转向实际动手环节吧。

另外除了这个系列以外，我可能还会开一个自己动手写小HTTP Server的项目。目标是写一个纯java的Http代理，初步是先实现接收Http请求的部分。参考nanoHttpd和mongoose项目。

L2TP（RFC2661）上来就说自己是扩展PPP协议（RFC1661）的，我看我还是先看一遍PPP协议吧。

而PPP协议是一个数据链路层协议，比TCP低两层，比IP协议都低一层。用普通的socket编程不能直接修改包头，所以我需要借助于WinPcap和libpcap库来获得对数据链路层的控制能力。

数据链路层啊，难怪比HTTP难懂，搞这东西要和Sniffer一样用WinPcap，这一点就让我觉得很高端了。

这种超级底层的冷门知识，估计对我的游戏开发工作是没有任何帮助的。不过毕竟工程师，拿这种阳春白雪的东西当业余爱好装个B也是好的。继续看吧。

RFC是什么，维基上有解释。按我的理解，就是一些通信、网络方面的协议和规则，有人把讨论后的结果整理成格式统一的文档，大家都遵守这个文档的话，各自做的软件之间就可以交流了。

举例来说，我上个月读了一份RFC2616，是HTTP 1.1协议，也就是我们现在最广泛使用着的一版HTTP协议。里面定义了客户端（浏览器之类）应该以什么格式内容发送请求(HTTP  Request)给服务器端，服务器端根据自己的情况，应该返回什么格式内容的响应(HTTP Response)。

最开始读这份RFC是因为我需要写一个HTTP代理程序，又毫无头绪，需要了解一些相关知识。

其实在读RFC之前，我尝试性地让代理把接收到的所有请求内容一字不差地转发给服务器端，再把从服务器端收到的内容全文转发给客户端，心想这就是标准的端口转发了吧，结果是代理运行起来一卡一卡的，而且卡得很有规律，每10秒可以读取一批请求，然后要卡10秒，才能读取下一批请求。因为对HTTP协议一无所知，所以当撞大运编程失败以后，我就只能老老实实的去看协议了。

在我花了20小时读完别人翻译的中文版RFC2616以后，我发现我爱上了RFC这个东西。

 

首先，RFC是第一手资料，非常有价值。

你想和别人探讨问题，他举出某HTTP教材里的内容，你举出RFC里面的内容，那结果肯定是你的证据说服力更强。毕竟写教材的人也是看完RFC去写的教材，教材已经是第二手知识了。

其次，RFC的格式严谨，而且只有干货没有废话，上来就可以大流量地吸收新知识，读起来很痛快。

我至今读过的技术书籍里，都没有任何一本有RFC这样清晰易懂的内容组织。不过拿一群人整理出来的RFC和一两个人写的技术教材来做比较，也是有点欺负人就是了。

 

读完RFC之后，再去写我的HTTP代理程序就如鱼得水了。因为目的明确，省去了很多摸索和撞大运的时间。

这种感觉就好象在游戏公司，程序员进项目组的第一天就被告知“游戏策划和美术音乐素材已经全部就绪，就等着您去编程了”时那种痛快的感觉。虽然我从来没体验过。

现在我的HTTP代理已经可以正常运转。虽然实现很简单很不守规矩，但并不影响使用。等下周把keep-alive也给实现了，在主要功能方面我就没有遗憾了。

 

关于RFC，HTTP代理这件事完成的很不错，接下来就要去找下一个战场了。

正好hacklu同学有一个需要搭建l2tp配ipsec的vpn的需求，而我又一直无法突破拖延心境去找资料设置这个东西。干脆，我自己试着写一个l2tp配ipsec的服务器端吧！

在公司用了这么久的git，这次拿到github上去试试身手。如果这次也能顺利搞定，那我就考虑定期攻克一个RFC文档了。

 

还是老规矩，先通读相关RFC，再设计和编程。

相关RFC有：

1. RFC2661 《Layer Two Tunneling Protocol “L2TP”》

2. RFC3193 《Securing L2TP using IPsec》

3. RFC2402 《IP Authentication Header》

4. RFC2406 《IP Encapsulating Security Payload (ESP)》

5. RFC791 《INTERNET PROTOCOL》

6. RFC2409 《The Internet Key Exchange (IKE)》

7. RFC1661 《The Point-to-Point Protocol (PPP)》

8. RFC1962 《The PPP Compression Control Protocol (CCP)》

…

卧槽，这个比HTTP代理程序复杂好多啊……依我挖大坑的经验，这种陨石坑我是填不上的。不过难得有一个可以让我学点东西的目标，不试试就放弃，也太可惜了。

hacklu用练字来磨练自己，那我就用啃RFC来磨练自己吧！

还可以趁机写一些RFC阅读笔记当日志，充充数量。毕竟最近几年的日志产量少得我都不好意思了。

又一个我认真待过的日志空间关闭了，上次是msn space。

我虽然很久不用百度空间了，但对他一直很有亲切感。提起百度空间，就会想起我的整个大学生涯，兼一半的留学生涯，我的第一批“网友”，我的一百多幅画，我初学编程时为一点小成就而喜悦，我意志薄弱时任性的吐槽发牢骚。

好东西为什么总是死的早？也许不是他很好，而是我对他产生了感情，感情深到同类产品的优势不足以抵消我对老朋友的留恋。确实，相比探险与开拓，我更倾向于恋家和守旧。

msn space, google reader, baidu空间，还有fileden网络硬盘，大的还可以算上verycd，115，以前的迅雷，我没用过的像google wave，google code，google buzz(…google你是关闭了多少业务= =)，delicious书签，等等。现在我还用着的evernote,dropbox,youtube,gmail,weibo,qq,xiami,github… 考虑到现在复杂的大环境，我越来越觉得把所有数据都管理在自己手里是很重要的。

现在我家里有一台synologyNAS（3TB，800MHz,128MB）,一台HP小服务器(500G+3TB,2*2.2GHz,4GB)，有一个同学的VPS的账号，一个同学的网页服务器的账号。

作为一个业余爱好，我想把我需要的数据都管理在自己手边。新业务出来了，只要把自己的数据导入导出一下就可以用，定期把网络上的数据同步回本地永久保存。嗯，能做到就好了。不过其实这事情本身意义不大，还是玩的成分居多。

不过，等我年纪再大一点，想回顾自己年轻时的足迹时，发现百度已经把日志彻底删除了，微博已经被新社交环境淘汰了，动画漫画已经没地方下了，就该骂现在的我为什么不勤快点把收集做好吧。所以这事情要说有意义呢，也算是有点意义。等闲下来好好计划一下，在github上开一个收集各平台数据的爬虫，和在本地管理各种数据的框架的坑吧^_^