TCP与去中心化_去中心化的服务器之间该如何连接

我暂时将直连对等通信看作是一个去中心化的实例。

都说互联网是去中心化的，其实并不是。虽然互联网的前身ARPA网的初衷是去中心化以防核打击，但发展到最后，显然这个目标并没有在互联网实现。

现代互联网使用更多资源跑B/S，C/S服务，用于资源的获取，而不是对等通信。资源曾经集中在门户，如今集中在云机房，而云资源必然构建在从属于某个公司的平台，显然不是去中心的。P2P曾流行，但很快被遍地打压而销声匿迹。

本文从TCP的视角刨一刨。

建立TCP连接，要有一个主动端和一个被动端，其中被动端在收到主动端的SYN时，必须已经等在那里。这就是Listener的由来。

Listener并不是必须要一直等在那里接受主动端的SYN，在主动端发起SYN前，敲一下门，即时唤起Listener也是可以。但这无疑增加敲门逻辑的复杂性，唤起Listener之前SYN到达怎么办，敲门后SYN迟迟不来，多久可以释放Listener，都是问题。

Listener常驻是最简单的方案。理论上，通信双方是对等的，但考虑到TCP的实现形式，就区分了服务器和客户端，常驻的Listener就是服务端，主动连接方便是客户端。这是我们都很熟悉的。

一个常驻的服务端并不适合对等通信，有谁愿意时刻准备着被打扰呢。常驻的服务端注定会造成资源集中。

简单讲，从一开始，互联网的雏卵中就没有一套适合去中心化的可用协议，开启互联网的唯一协议TCP是一个天生中心化的协议。

我们看看原始的第一版TCP，即1974年版是怎么说的，摘自RFC675：

TCP常驻端一开始就被类比为服务，它本来就是一个C/S模型：

• Listener在一个熟知的端口上等待任何客户端的连接。

如果用TCP实现对等通信，它应该是下面的样子：

是不是很讽刺，为了TCP对等通信，却要引入一个中心。该中心中继Client之间的通信，这像极了邮政服务。或者说回到了电话时代，那个TCP Server担当PBX交换角色，显然是一个集中控制单点。

将数据面优化一下，两个Client通信不必通过Server中继，但仍须借助一个Server提供信息，从而建立直接的连接。无论如何，这个Server即使作为控制器还是不可或缺。

TCP和去中心化是矛盾的：

• TCP Server部署在中心，所有客户端对等。
• TCP Server部署在边缘，端到端便不对等。

人们必须接受TCP服务器作为中心这个事实。资源向它集中就显而易见了。几乎所有TCP服务器上都有海量TCP客户端需要的资源，比如网页，音频，视频，转发服务，最终这些改头换面成了各种新概念，云原生，CDN。

这是一个普遍的模式，不仅限于TCP，如果我们选择使用UDP，依然会趋于中心化。

说到底，对等通信最重要的问题是“如何找到对方”。要摆脱中心控制，你必须能直接找到对方，但这可能吗？

现实中，若要找一个人，需要他的住址或电话号码，然而他的住址和电话号码均注册在某个机构，除非将这个机构控制的信息分布式去中心化，否则将无法实现真正的直连对等通信。

一种方案是广播这个信息黄页，形成共识，所有人都知道就没有秘密了，也就没人能集中控制。目前的DNS并没有去中心化的可能，它只是一来一回的Request/Response，如果将DNS解析放在区块链上，事情会变好吗？

如果通信双方的任何一方均在区块链上注册了自己的名字，最终解析到IP和协议端口，事情会好很多。

但新问题总会凸显，PoW算力会逐步集中吗？其它共识算法呢？为了获得共识，我们付出的代价能否被接受？集中化是熵减，在自组织系统最终溃灭之前，集中化似乎是趋势。从生物进化这个实例能看得出，进化出大脑和心脏和越来越复杂的方向是一致的，所以我对去中心化持悲观态度。

浙江温州皮鞋湿，下雨进水不会胖。