对问题的拆分
解决问题的最好办法是把问题转化为一个或者多个已知的问题。
当然天才会提出更好的回路，但是对于大部分人而言，都是路径依赖的产物。
虽然都是普通人，但有些人会不断的将自己的掌握的内容，迭代优化，融会贯通。
有些人的认知观就好像亘古不变一样，不想要变通。
以下提出一个快速解决问题的技巧，这对掌握问题并无太大的帮助，但可以针对某个特定的问题给出一个特异解。
在遇到一个比较棘手的问题，首先要了解这个问题的背景环境，即缩小问题的可能性。有可能是是一个特定的代码问题，有可能时验证想法，有可能是工程问题，有可能是寻求认同和理解，有可能是分享一些快乐和喜悦。
然后是针对这个问题，尝试进行输入和输出，观察输入和输出的可能性是否一致，如果运气好的话，这里就可以解决了。
如果依旧不行，则尝试把问题转换为已知的问题，通过破坏结构的方式，让问题转化为特定问题。
比如情绪问题的通解是认同和理解，但是其实和转化为指令执行。当我们无法窥见成因的时候，就强制问题进行演化，追踪变动。
这个其实比较像是在养蛊，就像是大公司的里的不同的项目组，没有人知道结果是什么，就先做，做着做着就知道了。 这个有前提，资源充足，即这个提议对方可以接受，在有些就是工具人的情况下，试着抛出来是没有任何反馈的，也可以用于自我定位。
我个人的习惯是，如果我在寻求一个意见，并且意见被给出的话，我会对这个意见给出反馈，这个就相当对加权，如果问题很大，我会征求多份意见，如果问题很小，那么会选择当即执行。这种即使的反馈感，是人与人之间最舒服的事情。
就像是在调试一份代码，不停的run,不停的error,如果编译很慢，就要考虑写法的问题，但是像是python,就可以不停的尝试。
所谓沟通，并不是一味的符合，也不是一味的反抗，而是需要在灌输的过程中，不断的给与一些反馈，用于确保自己没有理解错误。
在传输大文件的时候，数据校验时必须的。传完了，发现丢包了，在重复这个过程是很浪费时间的。
这个校验的结点需要自行判断。
有些时候这个节点就可以大很多，
UDP 就像是开会或者是讲课，就是一直发包，也不在意包的接收者有没有接收到。
个人可以针对意愿丢包，也可以提问申请重新发包。因为是一对多的关系，效率高。
TCP 是稳定包的最小单元。
有些反馈的包是延时的，发出去的时候，挺让人心烦的。但是在执行一些基础任务的时候，就很方便。
有些环境很艰苦，网速很差，比如发给旅行者号，那种时候，自主权就很重要。鞭长莫及，沟通起来，根本来不及，这个时候，就需要厉害的人。
有些环境网速很快，频繁的的反馈，最好一条指令下去，会给出多条反馈指令。并且我们希望机器有着良好的熔断机制，即不管怎么发，都不会炸，遇到错误指令会选择性的丢包。
执行过程中的关键指令需要反馈。
万能的网关可以适用任何设备，万能的设备可以适用任意信号。全能的代价是臃肿和成本高昂。