分享

这两天不想写这个东西，是为了避一避CRS3的锋芒，我现在非常理解那些和《阿凡达》同时上映的大片导演的郁闷！不过我这个东西会不会一不留神成为《拆弹部队》呢？嘿嘿嘿嘿嘿嘿嘿嘿嘿嘿……

3、“呼叫－应答”机制的失效

在上一篇屈指可数的回复中，我提到星际互联网将不会是基于TCP/IP机制的，有朋友表示不理解。其中主要的理由就是这节提到的“呼叫－应答”机制的失效。

这个机制可能是我们从来没有注意过的一个惯性思维。仔细看现在互联网的各种协议，我们会发现这种机制的身影遍布各处。TCP的三次握手是这种机制，所有的检测机制（不管是OSPF还是防火墙的状态热备，乃至服务器之间的备份技术）都是这种机制。发一个包过去，等待对方的响应，再做出回应，如果发了几个包没有响应，就认为对方失效了。可以说整个互联网都是建立在这种机制之上的。

这种想法其实是很正常的，我们现实生活中就是这样的。两个人聊天，一个人说完了，另一个人再说。打电话的时候，根据语言协议的不同，不同民族以“喂”、“Hello”、“moximoxi”之类的开头测试一下电话是否正常接通，然后再说话。我们的现实世界是这个样子，互联网有什么理由不同呢？

但是如果把这种机制引入星际互联网，问题就来了。最大的问题就是延迟问题，地球到月球1s多的延迟，貌似还可以忍受，地球到冥王星可是要6小时的延迟呀（光速也要6小时的说）。想想，打电话你说一句hello以后，要12个小时以后才收到一个hello回来，如果按照一般检测协议规定的，要等3个包没收到才确认对方失效的机制，你就要等24小时以后才知道对方断线了，要重新说一句hello。你不崩溃吗？

ok，人类目前的足迹还踏不上冥王星，但是登陆火星并建立工作在火星轨道的无人空间站并不会是很久远的事情吧。6万年来，火星离地球最近的时候也有5576万公里的说，也要3分多钟。况且在太空中的飞行器和地球之间的距离是不固定的，通信的时延响应的也是不固定的，这种不固定的时延对链路状态检测意味着什么，相信大家都可以想象。

4、真正的全双工，新的通信机制

如何解决“呼叫－应答”机制的失效呢？科幻巨匠阿西莫夫同志曾经在他的一篇短篇小说《我的儿子，一位物理学家》中，给出了一个老太太长途电话节省话费用的办法。简单的说，就是全双工工作模式，双方都不停的象对方发送信息，如果中间有接受不完整的信息就把这个问题插入都通信队列的后端。应该说我们现在的网络也是全双工的，但是具体到某一个特定的TCP连接，就基本上是半双工的了。而我们要实现的是真正意义上的全双工，不管你是否已经请求，我先给出响应，听起来不可思议，是吗？其实也没有什么了不起的，只要肯想，办法总还是有的。

对于一般性的数据，比如弯曲评论上面的所有数据，要让火星上可以很快的访问，最简单的方法就是在火星上某个数据中心租一台服务器，然后和地球上的弯曲评论的服务器不间断的同步，那边有更新直接发过来，这边有更新直接发过去。其实google或者其他CDN目前在地球上就是这么干的。

顺便附歪诗一首：君住过道南，我住过道北，奈何ISP不相同，见面还靠腿。一日CDN飞架南北，天堑变通途，ISP应无恙，当惊世界殊。

而“呼叫－应答”机制在火星范围内依然可以使用，或者说TCP/IP协议依然可以使用。但是在地球和火星之间走的一定不是TCP/IP，而是双向不间断的通信。如果有一个数据包丢失了，也不是TCP的窗口重传机制，而是对方把重新请求的数据包排在向地球传输数据队列的队尾，地球收到后，重传单个数据包，这样可以把整个系统传输数据的延迟降到最低。

当然这恐怕需要一个巨大的队列和队列的缓冲，一个数据包在收到确认之前要一直呆在队列和缓冲中。为了实现这一部分消耗资源的可控，可以采取逐跳中继的方法。比如在地球和火星之间的轨道上建立若干的中继站，站和站之间是点到点的链路，一个站收到上一个站传来的数据以后，就发出确认，让上一个站将对应的队列清空。

那么一些实时的数据该怎么办？比如一些传感器上的实时数据。没错，就是不管请求与否，都把数据传回来再说。那么，如果出现链路拥塞怎么办？也许可以采用类似于CPU的乱序执行技术？呵呵，开个玩笑。不过这确实是一个问题

那么，开视频会议要怎么办呢？——如果你是美国人，那就学美国老太太，换个开会的方法吧，你会习惯的。如果你是中国人，反正也就是做在那里听领导讲话而已，和在地球上没有什么区别的。

PS：这一部分写的有点乱，因为想到的东西很多，很多方面又相互关联，，大家先看个意思。后面还会再总结整理的。

分享