程序员读RFC，是一件很惬意的事情

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阅读笔记当日志，充充数量。毕竟最近几年的日志产量少得我都不好意思了。