Start a New Journey

這篇文章的由來在於客戶說的一句話：「Netlink 的效能似乎不太好」客戶口中的不太好指的是 Throughput 只有 10Mbps。本來嘛，我想之後才處理這件事情，但結果我的一個同事 York 抱著追根究底的精神進行了下面的實驗。首先，他用一支 user space 的程式來產生封包到 kernel space 的模組，模組收到以後就將封包打回 user space。簡單來講究是一個 echo 的行為。下面會列出這兩隻程式： 實驗平台：某平台 Kernel 版本：3.10 User Space： #include #include #include #include #include #include #include #include #include #define NETLINK_TEST 18 //#define MAX_PAYLOAD 1024 //#define MAX_PAYLOAD 2048 //#define MAX_PAYLOAD 4096 #define MAX_PAYLOAD 8192 #define MESSAGE_COUNT 1048576 struct sockaddr_nl src_addr, dest_addr; struct msghdr msg; struct nlmsghdr *nlh = NULL; struct iovec iov; int sock_fd; void main() { int _i = 0; time_t startTime = 0; time_t endTime = 0; sock_fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_TEST); memset(&src_addr, 0, sizeof(src_addr)); src_addr.nl_family = AF_NETLINK; src_addr.nl_pid = getpid(); src_addr.nl_groups = 0; bind(sock_fd, (struct sockaddr*)&src_addr, sizeof(src_addr)); memset...

語本禮記·檀弓下：「晉獻文子成室，晉大夫發焉。張老曰：『美哉輪焉！美哉奐焉！歌於斯，哭於斯，聚國族於斯。』文子曰：『武也，得歌於斯，哭於斯，聚國族於斯，是全要領以從先大夫於九京也。』北面再拜稽首。君子謂之：『善頌善禱』。」 不知為什麼，我一直對禮記中的這一篇印象深刻，大概是小時候記憶力比較好，所以一直刻劃在心中吧。之前有天我弟要我把時間留下來，要參加他們家的家庭禮拜，結果到了以後才發現原來是新居感恩禮拜（我說，你們小倆口根本已經搬進去很久了吧），然後居然還要說些祝福的話（喂喂，下次這種事要先講，我本來抱定只聽只吃不說話的態度啊），在想要講什麼的時候，第一個浮出的念頭就是「善頌善禱」的這個故事 ... ㄜ ... 不是聖經經文啊，所以就想找找，在聖經中哪一段有「新居落成」的相關經節，可以作為分享，結果就是以下面這段文章來做分享： 王上9：1-10 所羅門建造耶和華殿和王宮，並一切所願意建造的都完畢了，耶和華就二次向所羅門顯現，如先前在基遍向他顯現一樣，對他說：「你向我所禱告祈求的，我都應允了。我已將你所建的這殿分別為聖，使我的名永遠在其中；我的眼、我的心也必常在那裡。你若效法你父大衛，存誠實正直的心行在我面前，遵行我一切所吩咐你的，謹守我的律例典章，我就必堅固你的國位在以色列中，直到永遠，正如我應許你父大衛說：你的子孫必不斷人坐以色列的國位。倘若你們和你們的子孫轉去不跟從我，不守我指示你們的誡命律例，去事奉敬拜別神，我就必將以色列人從我賜給他們的地上剪除，並且我為己名所分別為聖的殿也必捨棄不顧，使以色列人在萬民中作笑談，被譏誚。這殿雖然甚高，將來經過的人必驚訝、嗤笑，說：耶和華為何向這地和這殿如此行呢？人必回答說：是因此地的人離棄領他們列祖出埃及地之耶和華─他們的神，去親近別神，事奉敬拜他，所以耶和華使這一切災禍臨到他們。」所羅門建造耶和華殿和王宮，這兩所二十年才完畢了。 在列王記上的記載裏面，所羅門花了二十年的時間完成了聖殿和皇宮的建造，而現在上帝來參加這個「新居感恩禮拜」。上帝說：「 我已將你所建的這殿分別為聖，使我的名永遠在其中；我的眼、我的心也必常在那裡。 」感謝上帝，這是上帝同在的保證，這是基督徒最喜歡傳講平安的福音：「以馬內利，上帝與我們同在」，以上帝給的祝福來說，沒有比這更大的。可是等等，接下來的話是新居落成時所該給的祝福嗎？一開始還好，可...

最近上班時間都會聽些講道，畢竟塞車實在是太嚴重了一點，也希望女兒可以在耳濡目染之下接觸到正統神學信仰的內容（這個可能太早了點）。前陣子下載了林慈信老師的「 章力生 神學講座：基督教與（西方）哲學的相遇 」，如果不是因為有讀過相關的內容，我想就我一個沒受過哲學和神學訓練的人大概聽不了多少吧。 不過裏面林慈信老師有一個很重要的提醒。林慈信老師說：「被歸正神學吸引的人通常會有兩種發展，一種是愈來愈順服在上帝的主權和帶領之下；另一種則是會離歸正神學愈來愈遠。」這裡林慈信老師所說的歸正神學指得是傳統加爾文的改革宗神學。其實這句話就邏輯上來說就和「動物可以分成兩類，一類是人，另一類不是人」一樣毫無意義，但卻讓我頗授震憾也讓我進行了反思。 我開始接觸歸神學是從聽唐崇榮牧師的講道開始，只是為了聽聽什麼叫作講了七八年的希伯來書。聽了以後發現，有好多的問題是我沒有想過的，有好多的經文是我沒有好好思考的，原來當個基督徒不是做一個世人所以為的「好人」外加相信耶穌從死裡復活就好了。我開始對神學以及這個和神學糾纏不清的哲學產生了興趣。插一句題外話，我認為唐牧師常常從哲學的角度切入信仰在現在並不是什麼好方式，因為現在的人愈來愈不讀書，也愈來愈缺乏哲學思辨的訓練（是說我也好不到哪裡去就是了）。被吸引後，開始去讀了神學以後才發現，天啊，這世界上充斥的理論也太驚人了吧 ... 以前許多在教會主日學完全不會被提到、或是被一般基督徒認為是錯誤的理論都有，不是像各種千禧年理論那樣不一定要確信的理論而已，而是像是聖經是不是神的話，因信稱義是不是正確的這些關乎就恩的知識。這些被包裝在學術的外衣之下，雖以神學為名，卻遠離了上帝，把上帝的話當成人類的作品來分析與討論而不以上帝為上帝，這就叫作被吸引進來，卻又被吸引離開吧，而我或多或少，也感受到了有這樣的人存在。 至於我，我只能說：「感謝上帝的保守」。我信上帝，是出於祂的恩，除此以外，我再也想不到任何理由。 弗2:8 你們得救是本乎恩，也因著信。這並不是出於自己，乃是神所賜的。 追根究底， 耶穌愛我我知道，因有聖經告訴我。

話先說在前面，這篇文章完全不會提到任何和 mininet架設、操作有關係的內容，因為這部份我都請同事代勞了（明明就是威脅加恐嚇還不給胡蘿蔔，誰叫我沒有胡蘿蔔） ，也因為這樣所以我沒有寫任何相關的文章，反正網路上已經一大堆了。 會想寫這篇文章是因為一個學生跟我說的一句話：「我的老師覺得 mininet 只是模擬器，不是很真實，所以他要我們參考網路上的文章，把 openvswitch（縮寫為 ovs）放到 AP 上來進行實驗。」聽到這句話我我第一時間完全不知道該怎麼回答。mininet 是不是模擬器？是！mininet 算是模擬器，既是模擬就有一定程度的不真實性，但是那個老師知道 mininet 的運作原理嗎？ mininet 是 Stanford 大學 Brandon Heller 的研發成果，它的概念很單純，就是利用 Linux Kernel 所提供的 network namespace 概念來建制虛擬環境，而每一台的 openflow switch 或是 host，其實就是一個獨立的 namespace。相關的概念可以參考我之前寫過的文章 linux network namespace 。而在 mininet 裏面，OpenFlow switch 的部份就是直接使用 openvswitch ，也就是說，使用 mininet 和把 openvswitch porting 到 AP 上是幾乎一樣的效果。知道這些細節以後，我在使用 mininet 上就會比較放心了。畢竟最後的問題就是一台主機的運算資源能不能負擔這麼多個 namespace 的問題，而這 performance 的議題難道會因為 porting 到 AP 上就不存在嗎？ 我在意的地方到不是老師的質疑，而是大部份我看過的學生，在 mininet 的使用上都不會去深入了解它的原理。為什麼被老師問一下就回答不出來，為什麼報告 mininet 只會停留在操作的層及而不會進一步去釐清它的實作技術？只會照著文件一步一步的操作，是很難做到舉一反三。其實我也不是多勤勞的傢伙，會去研究這東西只是因為在某次報告中要介紹相關技術，為了不要讓自己講的很心虛所以就稍微研究了一下。但盼望不要因為當工程師愈來愈久之後，就忘記了最初研究的樂趣。 ... 總的來說，這是我對自己提醒的文章。

會寫這篇文章最主要的理由在於，我發現很多人（包含我自己的長官以及眾多的指導委員）對於 OpenFlow APP的看法和我不一樣（這是客氣的說法，其實是 我認為他們的想法是錯誤 的）。所以囉，我決定整理一下自己的想法並寫在這裡，希望有興趣的人可以一起參與討論（雖然沒多少人看吧），一方面可以檢討自己的想法；二方面可以宣傳自己的理念。在這邊要先說明一件事，SDN 是一個概念而非實作上的技術，因此幾乎所有的東西都可以套入 SDN 的概念，因此我在這裡不談 SDN APP，而只單單著重在 OpenFlow APP。 很多人都期待 OpenFlow 可以帶來新的網路應用服務，well ... 單單這件事就有點問題，OpenFlow 算是一種 網路基礎建設的新型態架構 ，那麼我要問問，網路基礎建設所負責最主要的功能是什麼？答案很簡單，就是確保網路中的用戶端設備彼此之間能夠順利的連通，不管是 L2 switching 或是 L3 routing，那我們回到最基本的問題，請問目前的網路設備（我是指 L2/L3 的 switch 和 router）沒有辦法達成這一類的功能嗎？答案是，當然可以，不然我們現在用的網路是假的嗎？既然如此，那使用 OpenFlow 到底有什麼好處？使用 OpenFlow 最大的價值在於，我可以用新的想法來處理 L2 switching 和 L3 routing，藉由新的巧思，來達到比過去更好的網路效能或是使用率。有沒有例子？最簡單的一個例子就是 Broadcast 的封包處理概念，相關的細節可以參考下面的連結。 如何利用 OpenFlow 打造一個「無廣播」的網路環境 在這裡我可以斷言， 如果使用了 OpenFlow 的架構卻在思考網路問題上停留在傳統網路的思維，下場是網路的效能只會變得比過去還差。 現在面對的問題是，很多人問說，我可以不可以用 OpenFlow 來做到一些網路應用服務功能，如 Firewall、IDS/IPS 等，然後說用 OpenFlow Switch 會比較便宜，他們的理由是硬體規統、功能統一化，而且不用被網路大廠所把持。事實上，我也看到有台灣廠商投入在這一塊的發展（如果他們問我的話，我一定會加以勸阻），為了不想惹麻煩上身，姑且保留公司名稱不提。我為什麼認為這種發展方向是有問題的呢？第一， 你會期待網路基礎建設中每台設備都...

我個人比較喜歡的 IPC 技術是 Unix Domain Socket，因為可以 統一透過 File Descriptor 的處理機制來進行管理 ，如 epoll 或是 select 等。但即便是這樣，還是很多人會跟我說：「你有考慮過 Shared Memory 的方法嗎？效能應該會比較好唷。」我當然知道囉，不過隨著年紀增長，已經不再像以前一樣汲汲於效能上微小的差異（I mean ... 人的感受程度），而會把開發、維護的容易程度放在考量的第一位。所以我的第1選項目前都是：Unix Domain Socket，不但如此，之後也很 容易直接改成網路的 socket 程式 ，何樂而不為。但因為以後可能還是有遇到必須使用 Shared Memory 的情況，所以還是寫篇文章來紀錄相關的資訊。 Shared Memory 的 IPC 方式，顧名思義，就是兩個 Process 直接存取同樣一塊的記憶體空間。一般來說，兩個獨立的 Process 都會有各自的 Virtual Memory 位址管理，彼此之間是無法互相存取到的。而使用了 Shared Memory 的機制，系統核心就會準備一塊記憶體位置並讓兩個 Process 都能互相存取。用下圖可以表示 Shared Memory 和 Unix Domain Socket 的不同： 上圖左邊雖然是寫 Unix Domain Socket，但其實用 lo 來做 UDP socket communication 也是同一類。我個人認為上圖很明顯的說明了兩種方式的效率差異。在網路上看到一篇很不錯的效能比較文章，連結如下： Tcp Socket vs. Unix Domain Socket vs. Pipes vs. Shared Memory 這個網頁只有一個小缺點， 他不應該用 TCP Socket 來比較而應該採用 UDP Socket ，理由是 TCP 的 Overhead 大於 UDP，而本機端的溝通應該用不到那些機制。考量到外部網頁連結不一定會持續存在，因此我將相關的圖節錄如下： 接下來就是撰寫範例程式了。在這裡會撰寫兩隻程式，一支負責傳送資料，另外一支負責接受資料。範例的參考連結在下面： http://www.cs.cf.ac.uk/Dave/C/node27.html...

最近請人協助架設環境，但似乎進度不如預期。所以一怒之下（ 開玩笑的，我這人一向與人為善，您說是吧 ... ），就自己來架設NAT64的實驗環境，而這篇教學就是自己架設的過程紀錄。所以本篇文章告訴我們，少發脾氣比較好 ... （ 畫錯重點了吧 ） 在紀錄相關實驗步驟的時候，先來說明一下什麼是NAT64。Wikipedia上的描述是：「 NAT64 is a mechanism to allow IPv6 hosts to communicate with IPv4 servers. 」簡單來說，就是讓IPv6的設備能夠連上傳統IPv4網路設備的機制。怎麼做呢？看到NAT這幾個字眼應該用猜的也猜的到， 就是把封包的IPv6 Header替換成某個預先設定的IPv4 Header就完成了 。這裡要特別強調的一點，這個技術是 讓IPv6的設備能夠連上IPv4的設備，並不是讓IPv4的設備能夠連上IPv6的設備 ！理由呢？下面這個解釋是從 TAYGA 的網站上抄下來的： It is technically impossible for a translation system operating purely at the IP layer to allow IPv4 hosts to establish connections to any arbitrary IPv6 server. Such a system would need to represent every IPv6 server on the Internet with a unique IPv4 address, which is clearly infeasible given the size of the IPv6 address space. 當然我個人有另外非技術的解釋，NAT64是為了讓過去已經存在的IPv4 Server可以繼續提供服務，而如果連Server都已經是IPv6了，現在的client大部份都有IPv6的介面了啊，直接用IPv6來溝通不就好了。 這邊的紀錄著重在於架設環境以及實驗，相關工具的程式碼解析不在範圍內（因為我沒有這麼多時間）。 1. 實驗環境 實驗環境的圖如下： 在這邊解釋一下NAT64的設定。IPv4和IPv6是指NAT64自己的I...