我的家庭私有云计划-10-CSDN博客

嗯，上午调试程序，做发布前定稿，还挺忙的。

下午来接着说。

刚才登陆了一下家里的小服务器，中国大百科24CD已经全部下完了，正在解压到图书馆里面，呵呵，下了快1个月了，8G。

午饭前有个朋友问到ATOM性能不好的话题，其实这段时间讨论这个的朋友已经有点多了，我做个统一回答算了。

首先声明，我没打算只买一台计算机的，我希望的是这个云里面有多台计算机，有负责存储的，有负责性能计算的，有负责打酱油的，呵呵，就是做程序试验什么的。

其次，除了这台存储服务器，我为了节约电，其他的计算机恐怕不会7*24小时开机，只有用的时候开。

关于计算性能优先，有些朋友建议我考虑i3什么的，我确实没考虑，因为我没打算打游戏为主，儿子以后打游戏呢，我可能单独给他配一台游戏机，那是另外的话题，属于终端设备，不纳入这个私有云服务器集群考虑。

我预测我以后性能主要的需求是PS照片处理和录像剪辑处理，因为虽然我做的是高性能数据库，但我的数据库搁家庭来说，确实没什么用，我也不会傻到在家里部署一套数据库，高压力长时间测试，这个电钱太吓人，还是单位负担比较好。我这边只考虑家庭需求。因此，家庭的高性能计算需求我预测只有照片和录像。至少目前我还没有看到其他需求，当然，大家可以提啊，我可以纳入一体化考虑。

所以我的潜在采购目标是淘宝上，3k多的8核图形工作站，而不是用什么i3、i7这类民用CPU配出来的一台家用机，这是下一步计划，呵呵，先说出来，免得大家等急了。

目前搭建的主要是私有云的存储中心，数据仓库，暂时还没有考虑到而已。就这儿我都前后忙了差不多大半年时间呢。

所以我们慢慢来，呵呵，不急。

嗯，既然说了，就多说一点图形工作站，这个工作站肯定要买的，因为不止处理图像和视频，我对nVidia的CUDA一直很向往，我认为这是目前家庭可以获得的最廉价的并行计算物理平台了，一直想做这方面的实验。

但是民用显卡我认为基本上都是打酱油，我期待的是采购工作站的时候，精选一下显卡，最好是专业级的，我除了功能测试，还能在上面做点性能指标的测试，这是我的核心目的。

所以，既然有这个目标在后面压着，我自然可以忽视其他服务器的计算性能。

再讲一点我对服务器的认知啊，我是从386、486时代过来的人，那个年代的服务器要说CPU，连现在的手机都不如，但是，就是那样，我是亲眼看见过当时的服务器做了多少事情的，所以我一直不认为现在的服务器才叫服务器，当年其实已经能做事了。

换而言之呢，我其实觉得ATOM的1.6G主频，已经能做服务了，尤其是还是双核的情况下，服务器性能好坏，不看机器看应用，应用要求高性能了，没话讲，花钱搞定，但是实际生活中呢，又有多少高性能服务需求？大家去想。

所以我才在这个计划里面细分需求，试图通过多个服务器的精细搭配，以满足家庭需求为目标，实现一个家庭信息化中心这么一个私有云，是不是云不重要了，我认为最重要的是，家庭买得起，用得上，这才有意义。

还有一个很重要的设计思路是，我的方案应该不强调专业性，普通家庭用户，看了这篇文章，照方子抓药就够了，没必要什么都自己来，所以我尽量采用低版本的操作系统，客户端操作系统比如Win7来搭配服务器，因为毕竟普通家庭用户获得Windows Server版的可能性不大，会配置Server版复杂的组策略的更不多，因此没有实用价值。

虽然我现在使用的是2008R2，但是我不排除以后再换回Win7去，因为我觉得那个实验结果更有意义一点。

大家觉得呢？

好，言归正传，很多朋友都急于想看下文，我猜测，大家可能胃口吊最高的就是如何跨越内网实现安全的管理操作和高密级的信息流传递。

这个事情其实是我考虑的重点。今天上午还看了51cto一个帖子，讲用的是SoftEther来做vpn，解决跨越内网访问的问题，嗯，这是个法子，虽然我没用。随后我就做了实验，在小服务器上安装，但很遗憾，这个软件被2008R2拒绝安装了，虚拟网卡安装失败，可能是没有被微软认证导致，我在服务器上采用的是严厉策略，所以拒绝安装。

不过这不重要，因为我实际上没有使用这个法子。我找了新的解决方案，而且还很简单，普通家庭用户都可以用。

嗯，怎么说呢，这一讲起来又要做科普，我试着讲讲吧，讲不清楚呢，也别怪我，内容太多了。昨天我说了的，真要讲清楚，一本书呢。

P2P大家都知道吧，但是原理呢?我估计知道人不多了。

互联网用的是TCP协议，它底下还有UDP协议，其实我们目前的互联网应用，大多数就是这两个协议的组合，不排除有其他协议啊，但主要是这俩。

一般说来，TCP协议比较严谨，要求有握手过程，就是说我明确说明，要和哪个IP地址通讯，那么，网络协议栈层，中间路由设备会根据我的连接请求，找到目标，经过三次握手什么的，最后建立连接，OK。

实际上像http、https这类web应用，底层的连接协议基本上都是TCP的，这就带来一个问题，我们内网的计算机访问外网，比如我在家里，访问51CTO，我在内网，51CTO的服务器在公网，没问题，大多数路由器都允许这种连接形式，因为在公网上，我们的路由器WAN端口其实和51CTO的端口是差不多的，算是邻居关系，大家彼此很容易看见，目标明确，连接就成功。

但是，如果反过来，51CTO有台计算机想要连接我家里的计算机，麻烦了，我家里有好几台机器呢，请问你连哪台？51CTO毕竟不是我家里的蛔虫，肯定不知道啦，这目标说不清楚，就连接不成功了。

这就是说，我单位的笔记本在单位内网，我的小服务器在我家里的内网，是没有办法直接做TCP连接的，很艰难。必须在路由器上做端口映射。就是我指定外网的一台计算机，如果访问我路由器的80端口，路由器把它转移到内网的小服务器的80端口来，就好了。

但这又有一个问题，我家里的路由器是我在控制，我可以随便配，但是我单位的可不是，人家不可能在外网给我开辟这种端口映射服务，那人人映射，还不乱了？所以，端口映射可行，但是大多数场景不靠谱，因为技术可行，人不会允许。

所以我才在前面回应网友说，端口映射不行，我没有用这个办法。

注意哦，如果我仅仅要求我单位计算机访问家里小服务器，在家里小路由器上做端口映射就可以了，我心还要大一点，有时候我在家里，想看看单位的实验结果，还想从家里登陆到单位计算机，进一步登陆到我们内网服务器集群里面去看东西的，所以我要求的是“完全”双向连接。

事实上我现在就是这么做的，在单位登陆家里，在家里登陆单位，我甚至有时候在外面，还会先登陆到家里，再通过家里登陆到单位做点事情，甚至远程安排他们俩做点传输试验什么的。我认为这才叫全球可用。

这怎么办呢？这得用到P2P技术里面的一个分支，就是UDP打洞技术。

所谓“洞”的意思是这样的，内网计算机连接外网计算机，其实并不是真实的直连，而是内网计算机首先连接路由器，二者建立一个连接，再由路由器自己主动发起连接，向外网目标连接，这在路由器看来，就是两个socket，而这两个socket之间有关联关系，a来的数据，路由器要转到b，反过来，b来的数据，要转到a，路由器其实就是专门干这件事情的计算机啦。

路由器工作的时候，总是响应内网的某个TCP连接请求，采集信息，然后发起外网连接，转发两个socket之间的数据，直到某一方拆除socket，可能大家把它理解成电话的程控交换机比较好一点。

好，现在问题来了，TCP是有一个连接过程的，这期间路由器资料很明确，内网a要连接外网的b，嗯，允许，开始转发服务。

但是，还有个UDP协议呢，路由器不可能不支持UDP的，否则卖不掉。但UDP有个问题，它是无连接协议的，通常的情况是，内网a说了，老子这有个报文，路由器，你把它转到外网b的某个端口上去。嗯，它要有回应，你给我转回来。

这下路由器麻烦了，你这一笔交易没问题，我转出去，知道你们两个socket有关联关系，它回来的我给你转回来。

但是你们两个的UDP协议，不但没有建立连接的动作，连拆除连接的动作也没有，我咋直到你们什么时候通讯结束？路由器建立两个socket的映射关系是有很大代价的，起码得有个转发线程来伺服吧，如果每次UDP传输都这样只管建立不管拆除，那路由器死定了，几分钟之内资源就要耗尽，然后挂死。

所以传输上超时很重要，所有路由器在实施的过程中，都是设定一个超时，一定时间内，几百个毫秒内，我给你转，并且，如果你们俩一直连续通信，我就一直给你们转，但是，如果几百个毫秒你们都没动作了，那对不起，我拆了你们。这就是超时拆除。

拆除其实对于内网a来时，影响不大，它知道它的目标的，下次它发出通讯报文时，连接会自动再次建立。没关系。

但对于外网b来说，问题就很大了，因为它发的报文到达路由器时，路由器已经拆除连接了，不知道你发到我当前某个端口的报文应该转发给内网哪台计算机，因此传输就中断了。

这要形象点看呢，好比路由器就是一层泡沫薄膜，它上面可以开很多个洞，洞只能由内网计算机来开，这个洞呢，如果里面一直有东西钻来钻去，就一直开着，没有了，一会儿就自动愈合了。愈合以后呢，外面过来的东西被挡在外面，里面的呢，可以通过开新洞出来。就这么个意思啦。

嗯，这个时候带来一个问题，如果一个洞口在打开的时候，如果有第三方，就是其他一台计算机，送了点小礼物过来，能不能从这个洞口飞进去呢，最终到达里面的计算机手中？

答案是不一定，路由器有四种，最后面，也就是最严厉的一种，是不允许的。其他三种都允许。嗯，这个太专业了，不讲了。大家只要知道，大多数我们见过的路由器，都可以允许洞口打开的时候，第三方可以塞东西进去就好了。

嗯，说到这里，估计已经相当一批观众已经陷入晕厥了，呵呵，当年我看到这儿的时候，也晕过去了。

然后，我就问了一句大家可能现在最想问的话，这TNND有什么用？

用处大了，要知道，第三方可能也在一个内网里面，它前面也有这层膜。

故事的发生是这样的，公网有台服务器，专门用于给大家握手服务，内网的客户端每时每刻都会主动和公网这台服务器发UDP报文，前面说了，只要有流量，洞口就会持续打开，不关的。

公网服务器呢，当然知道目前哪个客户端现在和自己通讯的洞口是什么，就是IP+Port的一个组合了，当有a、b两个客户端想直接通讯的时候，怎么办呢？公网服务器把a的洞口告诉b，把b的洞口告诉a，然后，注意哦，a就是第三方，试图塞东西进b的洞口，进去了，b同样，也试图塞点东西到a的洞口里面。好了，连接建立了。二者发生直连。通讯正式开始。

这就是大名鼎鼎的P2P的握手过程，BT、迅雷、电驴、电骡、PPStream、PPLive...等等，都是这么来的。嗯，还有大名鼎鼎的Skype，网络语音电话。QQ大家知道吧？它是怎么传送的？猜猜看。呵呵。

这和vpn不一样，vpn是一台公网服务器负责转发，a的数据过来，转给b，b的转给a，注意，公网服务器很贵的，静态IP地址不说了，还有流量，这些流量都是部署服务器的企业花钱向电信买的，一般一个月就100M，多了可就贵了。所以P2P出现以前，公网转发服务，vpn非常昂贵，很少有人能用得起。

但是P2P出现后，情况不一样了，一旦ab知道对方的洞口，开始建立链路通讯，嗯，大家发现什么没有？公网服务器没什么事儿了。这俩哥们自己聊好了，公网服务器就是负责这个握手过程，带宽极低，所以成本非常便宜，几乎可以忽略不计。这就是为啥QQ、Skype、PP什么软件可以免费运营的由来，没有这个技术，他们赔死去。都给电信局打流量工了。

OK，既然上述理论可以成立，那么，我们在UDP上来自己实现一套TCP协议栈还难吗？本来TCP就是在UDP的基础上二次开发成的。呵呵。

那是不是说，只要底层我们修改一下协议，使用P2P技术，那么，我们可以自己构建一套TCP协议栈，这协议栈也是程序啦，别人能写，为啥我们不能自己写？

事实上我08年就干过这种事儿，呵呵，我自己实现过socket的，写过select、connect、close、send、recv之类的函数，嗯，朋友知道是什么吗？伯克利SocketAPI，查查去。

当然，网上有很多现成的P2P开源库，我当时被迫自己写是因为还有其他需求，就是穿越防火墙，一个防火墙，只能浏览网页，也就是说，只允许80端口的穿越访问，我的任务是要利用这个仅有的条件，打网络语音电话，还要保证报文的QoS质量，嗯，就是这么简单一件事儿。

后来呢，应该是现在还没有拦得住我的防火墙，呵呵，因为没人给我报bug。

那些说不要自己重复造轮子的朋友，这种轮子你哪找去？要不要自己造？

这算是数据传输领域近年来新出现的一个冷门专业啊，其实也不冷门，因为它正在变成大热门，建议有兴趣的程序员朋友研究一下，这个行业能赚钱的。

关键是太有用了，大家发现没？

当然，这个原理我知道，代码也有，不过，最终我没有用我自己的，因为我的东东没有经过商业化包装，对于普通用户来说门槛有点高，我找了半天，呵呵，其实就是花生壳，也已经开发出类似的东东了。

这就是向日葵。

嗯，写了不少了，休息一下。

预知后事如何，且听下回分解啊，呵呵。