嗯，上午調試程序，做發佈前定稿，還挺忙的。
下午來接着說。
剛纔登陸了一下家裏的小服務器，中國大百科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來做***，解決跨越內網訪問的問題，嗯，這是個法子，雖然我沒用。隨後我就做了實驗，在小服務器上安裝，但很遺憾，這個軟件被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。
那些說不要自己重複造輪子的朋友，這種輪子你哪找去？要不要自己造？
這算是數據傳輸領域近年來新出現的一個冷門專業啊，其實也不冷門，因爲它正在變成大熱門，建議有興趣的程序員朋友研究一下，這個行業能賺錢的。
關鍵是太有用了，大家發現沒？
當然，這個原理我知道，代碼也有，不過，最終我沒有用我自己的，因爲我的東東沒有經過商業化包裝，對於普通用戶來說門檻有點高，我找了半天，呵呵，其實就是花生殼，也已經開發出類似的東東了。
這就是向日葵。
嗯，寫了不少了，休息一下。
預知後事如何，且聽下回分解啊，呵呵。