好久没有来了，实在是太懒。
经常用SSH的动态端口forwarding 来FQ，使用像这样的命令：
ssh -D 9999 -f -C -q -N sshHost.somewhere.com
这个命令会建立一个tunnel到指定的远程SSH主机，这样你连接本机9999端口，并在所建立连接上读写的任何数据都会被tunnel到远端主机，从而达到FQ的效果。
一直以为SSH这个命令里面做了很复杂的事情（比如实现连接管理和端口映射）来实现这么一个功能，但总觉得对一个小工具来说，它做的太多了，而且这个显然不是SSH所应该focus的功能。直到某一天忍不住google了一把SSH的工作原理，才弄明白原来SSH支持这个功能并没有那么复杂，它其实实现的相当巧妙(参看比如https://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/）。
SSH的实现并不是想象的那样去做了复杂的端口映射和连接管理，而是巧妙的通过内置一个SOCKS proxy的方式来完成dynamic port forwarding的功能；而这个内置的SOCKS PROXY则利用SSH提供的基本功能（remote port forwarding）来提供服务。弄清楚它的做法之后，刚好觉得以前用的Ssh Tunnel Manager不是太好使（经常它自动建立的dynamic port forwarding给hang住，估计是GFW检测到可疑的连接做了什么手脚吧），便手动实现了一个java 版的tunnel manager（感谢D，ZF，google，github和开源项目……）。
简单来说，自己做的这个ssh tunnel manager通过一个类似heart beat的task 检查到特定站点的连接（比如到google），如果发现出问题了便自动创建一个新的tunnel，关闭掉老的tunnel。如果有兴趣的可以看看源码哈，并不复杂：https://github.com/BugsLord/jsocks。
这个小工具只能算一个by product，通过这件事我想说的是
1. 保持好奇心，有时候尝试去知其所以然并不困难（比如这次不过就是动手google 了一把，而不是仅仅停留在奇怪或猜测它是怎么做的层次）
2. 学会去build一个产品而不是去create一个产品。build意味着你可以通过使用一些已经很成熟的产品或组建来实现你自己的需求，从而大大降低产品的复杂度、节约大量的人力物力。比如SSH自身就没有去做自己复杂的端口、连接的管理和映射，而是利用SOCKS proxy来搞定；我自己写的这个tunnel manager也是利用了j2ssh这个开源库而不是自己从touch开始做。这个也是符合design principle中所说的favor composition……