RCViewer从启动至今，也差不多半年时间了。其间为稻粱谋，接了一些乱七八糟的活以资养家糊口，放慢了进度，但突然而来的疫情让人不得不宅下来。宅下来的这一段时间就成了RCViewer进展最为迅速的时期。
先是打通了三方安全信道。过程中有困难，克服困难的打怪升级历程。golang果然是最适合用来作为api服务器的语言，然而做其他用还是略显不足。比如对于dtls的支持，为了方便部署和编译，RCViewer本来想使用最native的golang style来做一个纯粹的支持RFC 3489， RFC 5389的stun server，但RFC定义的协议的开源实现，大家都是明文形式传输，对于节点本身的信息安全存在较大隐患，所以一开始我试图寻找一个安全的stun实现，结果当然是令人失望的。于是开启造轮子模式，但golang本身缺乏对于dtls的支持，想用native的golang来完成所有事情的幻想就此破灭。作为一个不纯粹的goer，我顺理成章地选择golang wrapper openssl的模式，来实现dtls交互，这一dtls安全信道的实现，极大加速节点间安全信道的建设。
节点间的传输分为信令和数据，数据是屏幕流数据，信令是诸如连接请求，连接响应，动作控制等等。信令始终是在安全信道传输，数据则编码传输。何为编码？http传输明文，https传输加密报文，加密报文是明文的一一映射。编码则不然，通信中常用的LDPC，存储中常用的RS，是典型的编码技术。编码在传输的数据中加入冗余信息，实现前向纠错，可有效解决信道不可靠引入的传输错误。无码率的编码技术，则可以实现更加快速，对抗信道抖动更好的传输协议。编码后的数据想要被恢复，需要实现完整的解码算法，了解编码参数，了解分片机制。信道传输编码数据，相当于做了天然的加密，因此，屏幕流的传输，也是通过一种非传统的安全信道。
至今天，RCViewer已经完成了大部分的基础能力建设，而且由于条件所限，只有一个志愿者节点供测试的情况下，还额外开发了内网自动探测模式。公网使用了分布式的relay节点取代了传统P2P传输中的turn server，内网则使用direct link提升性能。接下来的工作主要还是集中于将开发完成，次之为将产品稳定下来，再次为完善当前产品功能，然后可以开始内测，再次之为优化中继调度和传输协议，使之能够又快，又好。
所以，谁说多快好省不可得！
BTW：对于relay节点，我希望能设计一种激励机制，不知道哪里有大牛可以教我？
