golang是特别不适合拿来做应用层可靠协议开发的语言。所有的可靠协议都依赖于连接状态，在讲究并发的场景下，所有的状态都依赖于事件，所有的事件都依赖于内核文件描述符，问题是，在可靠场景下，我们常常需要将一个端口用作一块网卡，一块网卡可以有65536个描述符并发处理事件，一个端口却只有一个描述符，这一个描述符需要模拟出65536个描述符的事件处理效能，这本来就是令人头大的问题。golang本身的协程机制----固然golang和大多数的协程实现不尽一致----导致每一个事件的处理都应短暂，且事件之间应是无状态的，如果对于可靠协议各阶段的业务与事件理解不到位，极其容易实现出资源有余，而协议效能低下的情况。
为什么要有上面一段呢？因为目前的Sia，IPFS，Storj，Swarm都是golang实现的，这些实现都是在应用层实现基于udp的可靠传输协议，做到点对点数据存储与共享，问题是，我猜测这些项目，包括现在的所有区块链项目，都缺乏网络传输专家的加持，所以他们的传输实现显得非常荒谬。讲真，网络传输是靠时间积累的东西，TCP发展了半个多世纪，才发展出BBR，更不用说二十年不到，大多数时候处于松散研究状态的去中心化传输。从BT开始到几个已经ICO大大笔美刀的存储项目，在传输上，可以说都处于简单粗暴的状态，更不用说与现有网络的亲和策略。
IPFS事实上就是一个BT协议，而BT的底层是uTP。uTP在传输上实现了AIMD，这是从传统TCP继承的东西，经典而有用。顺便说一句，TCP网络本身是一个混沌系统，发送方与接收方都不知道网络的状态，他们既不知道是否能继续发送，也不知道收不到是否合理，唯一能做的就是试探，所以大神们都说TCP是一个控制系统，而不是传输协议。然而，AIMD会导致网络的轻微拥塞，从单条链路看，网络总是处于将丢包而未丢包处。问题是在分组交换网络中，物理链路是被分时复用的，单条链路能探测到的拥塞点，在多条链路时，可能已经产生极大丢包。所以单条链路探测的AIMD总是不准确的。因此，在IPFS上，对于时间不敏感的存储、下载场景，大概无压力，但如果涉及到流媒体传输，IPFS怕是力有未逮。
Storj的问题是什么呢？Storj也使用了uTP，问题是，Storj也没有搞懂AIMD，他们粗暴地设定了一个固定速率，这让我简直不知道怎么评价他们的传输实现。Sia的实现并没有使用uTP，Sia实现了自己的RateLimit，以此来控制报文发送的Pace Rate，问题是Sia的传输实现不是事件驱动的实现，他们使用了睡眠，然而睡眠的时候，连接是不能感知链路的变化的，因此发送端对于链路是否能继续容纳报文，是后知后觉的。
那么，是不是这些存储设备都不能用呢？恰恰相反，都能用，遗憾的是，也仅止于能用，如果想用他们来实现其他更加高效的传输，无异于痴人说梦。讲到底，这些东西都不过是TCP在应用层的重新实现，而现在所有的重新实现都还处在TCP最早期的阶段而已。TCP最早期的阶段甚至没有拥塞控制，大家都可劲儿使用链路，直到某天，有位大神注意到他的报文经常不能按照预期抵达，于是提出了拥塞理论。半个世纪后，拥塞控制算法逐渐成熟----其实离成熟还很远----我们才能在有很多人捣乱的网络上享受流畅的传输服务。然而伟大的TCP也自有缺点：超时重传实在是不准确而又浪费带宽，RTT又实在测不准，于是才出现了一系列的补救措施，形成拥塞控制这一整套的特定技术。
IPFS提出要做去中心化网络基础设施，但从技术架构上来看，实在是不足够，然而做一个去中心化的存储设施却绰绰有余。相较于大陆某几家专注于做应用甚至于连应用都没有做好的厂商----没错，不要心虚，我说的就是你们----IPFS从概念上算是挺有创新的项目了。
