这几天在博客园上跟一个也是最近才开始研究TOR的大佬聊了聊交换了信息，才发现自己确实还有很多技术功底需要积累。从前面我写的内容看，很多东西都没有挖掘太过底层，个人来说还是理论学习多于实践的多，大佬长我14岁，14年间的工程经验可以使他阅读开源项目的时候更敏锐更灵敏地嗅探到作者做法背后对性能，对逻辑，对跨平台编译，对系统架构方面的影响。可以很直接地做出一定的推论，可以比较有依据地判断“行”还是“不行”。作为一个刚开始进入计算机世界的人来说，一度总是认为什么都有得做，而忽略了这背后带来的“成本”和“难度”。诚然，什么都是可以实现的，比如说改一下LINUX内核啊，比如说黑进某某大厂的主机啊等等。但可以是可以，并不现实。大佬的出现给了我很多建议和思路，让我一开始很多想法得到了支持，也有一些想法被证实不可行。我也希望跟在别人后面去学习，去实践，而不用自己去踩过每一条路上的坑。
TOR的源码确实很简洁很优美，曾经认为源码阅读是一件很费神的事，毕竟怎么可以做到对那么大的系统一个总体的感知呢。但其实只要有一定的计算机理论基础，随着不停地看见新的模块不停地发现新的内容，新问题会不断地出现，也会不断地被解决，在解决的过程中脑海会逐渐织出这个源码的模型，哪个部分会做什么，哪个部分具体会怎么做，加上Doxygen生成的文档可以很直接地找到函数的调用链及函数的解释，所以我越读越轻松，越读越惊讶于开发者的成熟老练。
至于真正要做的，我认为还是要大胆尝试一下，TOR里面有个连接填充的功能，里面的填充数据元好比HELLO确认报文一样，大多数情况下是用作确认和保持连接活性，我决定用一定量的padding数据元来完成通道流量的填充。似乎我也逐渐找到了进行填充时的完整逻辑，填充发生于链路空闲，或者说链路仍需要被维持，我们还需要找到一个padding cell具体有多大，来确认最终的流量填充方案。
可能限于我的了解，padding cell并不可以这样用，但似乎看来只有这种类型的数据元才是对链路影响最小的，姑且一试。
然后怎么测试论证似乎成为了问题，TOR原本有做流量混淆的功能，他们在本地区所使用的obsf4网桥就是为了规避流量审查的功能，将TOR流量套上一层HTTP或者什么其他的壳进行伪装以不被拦截下来。但看了看似乎源码里并没有这个功能相关的代码，而且似乎被实现在了obsf4里面，而这个项目又是GO写的，这就触及我知识盲区了。
毕竟我只有自己一个人，而不是一群人。没有人和我交流没有人帮我一起发现问题一起阅读，没有强制力约束我也懒得约束他们，要是我给他们开工资那还好说。但他们就是觉得不会有成果，所以放弃了。而我做至如今，就是为了要出成果让他们觉得愧对。倘若最终结果也不好，那我真的，，成吧，时间费去了，却一无所有。
但我还年轻，我想有始有终。