個人家庭私有云計劃-10

 嗯，上午調試程序，作發佈前定稿，還挺忙的。

下午來接着說。

剛纔登錄了一下家裏的小服務器，中國大百科24CD已經所有下完了，正在解壓到圖書館裏面，呵呵，下了快1個月了，8G。

午餐前有個朋友問到ATOM性能很差的話題，其實這段時間討論這個的朋友已經有點多了，我作個統一回答算了。

首先聲明，我沒打算只買一臺計算機的，我但願的是這個雲裏面有多臺計算機，有負責存儲的，有負責性能計算的，有負責打醬油的，呵呵，就是作程序試驗什麼的。

其次，除了這臺存儲服務器，我爲了節約電，其餘的計算機恐怕不會7*24小時開機，只有用的時候開。

關於計算性能優先，有些朋友建議我考慮i3什麼的，我確實沒考慮，由於我沒打算打遊戲爲主，兒子之後打遊戲呢，我可能單獨給他配一臺遊戲機，那是另外的話題，屬於終端設備，不歸入這個私有云服務器集羣考慮。

我預測我之後性能主要的需求是PS照片處理和錄像剪輯處理，由於雖然我作的是高性能數據庫，但個人數據庫擱家庭來講，確實沒什麼用，我也不會傻到在家裏部署一套數據庫，高壓力長時間測試，這個電錢太嚇人，仍是單位負擔比較好。我這邊只考慮家庭需求。所以，家庭的高性能計算需求我預測只有照片和錄像。至少目前我尚未看到其餘需求，固然，你們能夠提啊，我能夠歸入一體化考慮。

因此個人潛在採購目標是淘寶上，3k多的8核圖形工做站，而不是用什麼i三、i7這類民用CPU配出來的一臺家用機，這是下一步計劃，呵呵，先說出來，省得你們等急了。

目前搭建的主要是私有云的存儲中心，數據倉庫，暫時尚未考慮到而已。就這兒我都先後忙了差很少大半年時間呢。

因此咱們慢慢來，呵呵，不急。

嗯，既然說了，就多說一點圖形工做站，這個工做站確定要買的，由於不止處理圖像和視頻，我對nVidia的CUDA一直很嚮往，我認爲這是目前家庭能夠得到的最廉價的並行計算物理平臺了，一直想作這方面的實驗。

可是民用顯卡我認爲基本上都是打醬油，我期待的是採購工做站的時候，精選一下顯卡，最好是專業級的，我除了功能測試，還能在上面作點性能指標的測試，這是個人核心目的。

因此，既然有這個目標在後面壓着，我天然能夠忽視其餘服務器的計算性能。

再講一點我對服務器的認知啊，我是從38六、486時代過來的人，那個年代的服務器要說CPU，連如今的手機都不如，可是，就是那樣，我是親眼看見過當時的服務器作了多少事情的，因此我一直不認爲如今的服務器才叫服務器，當年其實已經能作事了。

換而言之呢，我其實以爲ATOM的1.6G主頻，已經能作服務了，尤爲是仍是雙核的狀況下，服務器性能好壞，不看機器看應用，應用要求高性能了，沒話講，花錢搞定，可是實際生活中呢，又有多少高性能服務需求？你們去想。

因此我纔在這個計劃裏面細分需求，試圖經過多個服務器的精細搭配，以知足家庭需求爲目標，實現一個家庭信息化中心這麼一個私有云，是否是雲不重要了，我認爲最重要的是，家庭買得起，用得上，這纔有意義。

還有一個很重要的設計思路是，個人方案應該不強調專業性，普通家庭用戶，看了這篇文章，照方子抓藥就夠了，不必什麼都本身來，因此我儘可能採用低版本的操做系統，客戶端操做系統好比Win7來搭配服務器，由於畢竟普通家庭用戶得到Windows Server版的可能性不大，會配置Server版複雜的組策略的更很少，所以沒有實用價值。

雖然我如今使用的是2008R2，可是我不排除之後再換回Win7去，由於我以爲那個實驗結果更有意義一點。

你們以爲呢？

好，言歸正傳，不少朋友都急於想看下文，我猜想，你們可能胃口吊最高的就是如何跨越內網實現安全的管理操做和高密級的信息流傳遞。

這個事情實際上是我考慮的重點。今天上午還看了51cto一個帖子，講用的是SoftEther來作***，解決跨越內網訪問的問題，嗯，這是個法子，雖然我沒用。隨後我就作了實驗，在小服務器上安裝，但很遺憾，這個軟件被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你們知道吧？它是怎麼傳送的？猜猜看。呵呵。

這和***不同，***是一臺公網服務器負責轉發，a的數據過來，轉給b，b的轉給a，注意，公網服務器很貴的，靜態IP地址不說了，還有流量，這些流量都是部署服務器的企業花錢向電信買的，通常一個月就100M，多了可就貴了。因此P2P出現之前，公網轉發服務，***很是昂貴，不多有人能用得起。

可是P2P出現後，狀況不同了，一旦ab知道對方的洞口，開始創建鏈路通信，嗯，你們發現什麼沒有？公網服務器沒什麼事兒了。這倆哥們本身聊好了，公網服務器就是負責這個握手過程，帶寬極低，因此成本很是便宜，幾乎能夠忽略不計。這就是爲啥QQ、Skype、PP什麼軟件能夠免費運營的由來，沒有這個技術，他們賠死去。都給電信局打流量工了。

OK，既然上述理論能夠成立，那麼，咱們在UDP上來本身實現一套TCP協議棧還難嗎？原本TCP就是在UDP的基礎上二次開發成的。呵呵。

那是否是說，只要底層咱們修改一下協議，使用P2P技術，那麼，咱們能夠本身構建一套TCP協議棧，這協議棧也是程序啦，別人能寫，爲啥咱們不能本身寫？

事實上我08年就幹過這種事兒，呵呵，我本身實現過socket的，寫過select、connect、close、send、recv之類的函數，嗯，朋友知道是什麼嗎？伯克利SocketAPI，查查去。

固然，網上有不少現成的P2P開源庫，我當時被迫本身寫是由於還有其餘需求，就是穿越防火牆，一個防火牆，只能瀏覽網頁，也就是說，只容許80端口的穿越訪問，個人任務是要利用這個僅有的條件，打網絡語音電話，還要保證報文的QoS質量，嗯，就是這麼簡單一件事兒。

後來呢，應該是如今尚未攔得住個人防火牆，呵呵，由於沒人給我報bug。

那些說不要本身重複造輪子的朋友，這種輪子你哪找去？要不要本身造？

這算是數據傳輸領域近年來新出現的一個冷門專業啊，其實也不冷門，由於它正在變成大熱門，建議有興趣的程序員朋友研究一下，這個行業能賺錢的。

關鍵是太有用了，你們發現沒？

固然，這個原理我知道，代碼也有，不過，最終我沒有用我本身的，由於個人東東沒有通過商業化包裝，對於普通用戶來講門檻有點高，我找了半天，呵呵，其實就是花生殼，也已經開發出相似的東東了。

這就是向日葵。

嗯，寫了很多了，休息一下。

預知後事如何，且聽下回分解啊，呵呵。