工欲善其事,必先利其器

昨天剛好有機會跑去廠商的機房那邊做一個 POC (Prove Of Concept),雖然也是如莫非定律般的從下午搞到晚上快 11 點才出得來,而且還是個失敗的 POC。但正所謂三人行必有我師,今天還是留下個小驚喜。

驚喜就是,登登登… 這個吸在機櫃上的 LED燈

由於 POC 進行的不是很順利,有些空檔時間我就抓著對方問這個幹什麼的?吸在上面好像很酷,但實際上有什麼用途呢?

這廠商其實也挺妙,看起來他也挺自豪能想到這一招,馬上就 demo 給我看,第一,機櫃不是都有一些縱深嗎?儘管機房有公共照明,但機櫃基本上只有前後開孔,一般的公共照明是不足以照到機櫃裡面的,所以萬一有東西放比較深,或整線時剛好線藏在比較裡頭時,就可以拿來照:

這樣子是不是比較輕鬆也清楚多了?據這位老兄所述,以前他在照這類東西時,常會伸頭進去機櫃內看,那不但不符合人體工學,也容易有碰到線路的風險。當然這張圖我原本是想要照對方實際的整線狀況,但考慮到自己手殘會不小心動到線路的風險,還是用這個示意圖就好。

另外就是要看乖乖的保存期限也是很方便喔。隨著年紀越來越長,彎個腰都可能卡到的情況也都可能發生在自己身上了,LED磁吸燈這種隨處可見的東西並不怎麼高科技,但這位老兄會觀照自己的日常動作進而利用身邊的小東西來改善,的確是小弟值得學習的一點。

DevOps in Action, DevOps 日常/OpsDev 日常 – F5 DataSafe

起因來自於最近我常掛在嘴邊的一句話:誰上了雲端之後還用 F5 Load balancer 啊?上 Google Cloud 用的當然是 Google Cloud Load Balancing,上了 AWS 之後用的就當然是 Elastic Load Balancing,沒想到一句我看是理所當然的事情,同事間因為不同的角度,不同的專業背景,而有了不同的看法,也難怪有人說 DevOps 是一種文化轉變、是一種變革。由於我們公司的歷史說長不長,說短也有個十來年了,當初一開始經營時並沒有遇到雲崛起(AWS 崛起)的年代,所以僥倖的至今還幫客戶維運了不算小的自有機房,所以我們公司和一般使用純公有雲的公司不太一樣,我們有網路工程師、系統工程師甚至於值班工程師的配置。

這個故事開始於一位資深的網路工程師,何謂網路工程師?簡單的說就是那種有 CCNA, CCNP 甚至於有 CCIE 認證的專業人士,他們的日常工作項目就是在管各種硬體式的 Network Switch, Router, Firewall, ISP 線路, 流量一般來說,Load Balancer 由於功能或操作上也比較偏向於網路設備,所以在我碰到的公司裡,這設備一般也是歸網路工程師來管。

最近有天就產生了下面這個對話:我覺得 Clouding 上的 Load Balancer (Google or AWS) 固然便宜又方便,但是我不覺得 F5 比較差,而且看起來 AWS 就有提供 F5 的雲機器,也許我們可以考慮採用 AWS 上的 F5 雲機器服務,上次我去聽了 F5 的研討會,他們有個功能超神的,啟用之後就可以防 bot (機器人, 大概專指惡意的 bot, 例如來猜帳密的那種),還可以防中間人攻擊讓使用者帳密外洩之類的,最重要的是應用程式都不用改,F5 會自動地把 Javascript 插入在你的應用程式裡就可以作用了。

這位網工的伙伴講的很興奮,我聽了卻滿腦子黑人問號。我個人常習慣會把 IT 類的工作畫一條光譜線,一端是純開發端,也就是寫程式的啦,另一端就是純業務端,簡單來說就是不寫程式但懂客戶需求的,IT 相關的工程師,不管是管系統或管網路的,大抵來說可以算是在中間,意思就是網路工程師對於程式方面算是一知半解,知其然但不知其所以然,對於需求方面所知也是半桶水,當然這麼說是有點難聽了,事情總是可以從各種面像來看的,正面來說網路工程師是兼具兩者所長,所以可以遊走於自行開發和廠商解決方案之間,糅和出一個比較好的解決方案出來。

1

但是以這個例子而言,我們對於 F5 的這個 Advanced WAF 產品該如何取捨?我相信在傳統的分工情境下,大概不外乎就是網路工程師找廠商來 POC (Prove of Concept,概念驗證),以這個例子來說,我猜驗證的方式可能就是廠商去準備個攻擊的方法(當然這方法不會是廠商自己發明的,也許是來自於知名白帽駭客,也許是來自於某著名安全機構的概念性攻擊方法),然後測試看看裝載 Advanced WAF 前、後的差別,稍微大一點的組織,這件事情大概就很難邀請開發單位一起加入驗證了,一來也許是開發單位的人、產品或部門很多,不太可能都抓來一起驗證,一來可能是這公司的系統這邊也外包、那邊也外包,一般的公司就會認為這是網管自己的工作,不太可能邀請太多的關係者進來。

但是今天我們要打破這種傳統,單純從技術性的角度來分析這個產品,當然之所以能做到這件事,也是和我一向非常喜歡的 F5 的開放性有關,F5 大概是我看過文件和技術最開放的網路產品吧?文件整個豐富到不行,最重要的是這一大堆文件都還有人在維護的,有新版本時每個文件都會被重新檢視它的適用性,所以以下就開始我的技術分析。

DataSafe 算是 F5 Advanced WAF 裡的一個功能,Advanced WAF BIG-IP 13.1.0.2 開始提供,DataSafe 這功能就一併上市了。在以往的 Web Application 裡,瀏覽器端(或稱為 Client ) 其實是沒有任何保護的,既使是用了 SSL ,一旦使用者終端(PC, NB, 手機, 平版…) 被駭客入侵了,駭客就可以從瀏覽器端、從 OS 上側錄鍵盤或畫面等方式來劫持使用者的敏感資訊,以下是 F5 官方介紹關於 DataSafe 的影片及資料:

F5 DataSafe 介紹影片

F5 DataSafe 介紹文件

DataSafe 這個功能看起來是個執行在瀏覽器端的程式 (Javascript ?) ,藉由主動的置入 F5 所謂的 DataSafe Javascript 程式碼,幫你把敏感欄位在瀏覽器端就加密的方式,可以避免當前常見的 1)瀏覽器 plugin 問題 2) 中間人功能(有一些藏在本機把你信賴憑證偷換掉來偷聽的),然後在 F5 上就解密掉,所以讓你的 Web Application 不用修改就可以加上這個功能。

但是老實說,不管從文件上或 Youtube 影片上看來,這個機制不外乎是 1) 把程式上的 input box ID 給換給怪名字(F5說這個叫 Obfuscation) 2) 把敏感欄位資料 scramble 一下,我們可以想像的是,既使是入侵者,大概也不想要每天叮著你的網路流量去抽絲剝繭的找出敏感訊息,更何況是那種大量入侵一堆電腦的駭客,他們更不可能去分析那麼大的流量,所以可以做的就是去篩選出一些關鍵欄位或頁面來「偷聽」,這時候把欄位名稱亂取名或資料加密後,對於這類非針對性的駭客而言,應該會有一定的效果,這個道理就像是以前大家都會為自己的愛車加個方向盤鎖,偷車賊看到一排車子,為了怕麻煩就會懶得對有方向盤鎖的車子動手。

聽不懂嗎?這份 F5 文件對於 HTML Field Obfuscation 講得更仔細了,文中的兩張圖更是 清晰:

2.jpg
3.jpg

F5 這個機制做的好的地方是,他不用你自己動手去改程式,從影片看起來,你只要在他的管理介面上操作一下,這個機制的程式碼就會自動的插入在你的網站中,我想這對於許多的網管人員來說真是一大利器,因為我相信絕大多數的網管人員如果不是不會寫程式,就是程式和他不熟,至少那種有能力去寫出一個稍具規模網站的網管人員我是沒見過,能靠著 F5 這個產品就把網站漏洞給 patch 掉的這種外掛,相信在許多網管人員眼中都是神器了。

4.png

但實際上這件事有這麼難嗎?這不就也是支程式?人家文件裡也表明了這就是個把 Client 端欄位名稱加密然後配合 F5 server 上的解密行為,在這裡先讓我們看看 F5 自己的網站:

5.png

F5 似乎很顯然的沒有在他這個網站放入 DataSafe 的技術,因為我這個「中間人」利用 Developer tool 來觀察時可以很輕易的看到我自己的帳號和密碼,連帶的帳密的欄位名稱也很明顯,不符合 F5 文件裡的敘述

6.png

F5 網站自己沒有使用的原因我們難以得知,但從開發者的角度來看,既然知道了這種機制,那自己來實做會是困難的嗎?

讓我用 HTML Obfuscate 這個關鍵字來 google ,其實可以發現有很多網站在「教」大家怎麼做,例如這個,你可以把想要「Obfuscate 」的 HTML 語法貼上去,這網站就會幫你產生出攪亂後的語法:

7

當然如果你稍微比對一下 F5 的文件之後,會發現此 Obfuscate 並非彼 Obfuscate F5 的機制可不是這種單純把 HTML 語法攪亂丟到 client 端這麼簡單的,F5 提供的 Obfuscate 機制基本上應該是種非對稱式加密機制的「攪亂」,也就是被 F5 「攪亂」的 HTML 語法經由下一次 HTTP Post ( HTTP Get) F5 時,F5 會自己反解密回來,而且每一次「攪亂」出來的值都不會一樣(請參考這篇文章,這文章還提到可以抵禦的實際場景IP慢速攻擊猜帳碼)

所以說相較於一般網路上可以查到的 Obfuscate 方法,F5  DataSafe 的作法還是挺先進的。我們在網路上看到的都是屬於入門級的,這種入門級僅利用 client javascript HTML 語法攪亂的方法,對於 Client OS 的入侵可能有點混淆效果,但是對於 Man-in-the-browser 的攻擊效果就有限了,由於這類入門級的 Obfuscate 方法只對 Client 端攪亂,實際上要往 Server 上送 HTTP Post HTTP Get 時,還是得恢復原有的內容,這對於 Man-in-the-browser 的的攻擊就完全無效了。

所以我的結論是要說 F5 DataSafe 真的很神嗎?說難不難,說簡單嘛… 就我初步的 google 結果,網路上要找到現成類似 F5 做法的範例的確不太容易,但這並不是沒辦法自己撰寫的,只要開發人員願意,把幾個欄位名稱做個加解密機制基本上是一片小蛋糕來著,只是看你願不願意做這件事而已。

為什麼我特別要提到「願不願意」做這件事?這就得回到這種抵禦攻擊的方法是否有效了,假設一般稍有腦袋的猜帳密攻擊會用一堆IP來進行下面這類慢速動作:

8

當我們用了 F5 DataSafe 類的欄位加密機制後,攻擊者就無法很簡單的利用 ‘User’ ‘Pass’ 兩個欄位名稱來進行程式化的攻擊,因為每一次 F5 跑出來的 ‘User’ ‘Pass’ 欄位名稱都會被改變

例如由這個:

9.png

被攪亂變成這個:

10

那,把我的攻擊程式改複雜一點呢?稍微用人眼看一下這個例子,發現 username 欄位名稱都是以 <input type="username" name=" 這個 pattern 開頭,結尾於一個單引號,另一個 password 欄位以此類推,這不就也很快的破解了?

所以說到底,正所謂道高一尺,魔高一丈,這和偷車賊怕麻煩不偷有方向盤鎖的車子意思一樣,有做的可以對一般通殺型的駭客起一些阻嚇作用,但是對於那些專門特定來找你的惡意駭客,也就是所謂的針對式攻擊,不管是買 F5 來檔或是自己寫程式來檔,都很難依靠單一機制來防止入侵,那要做多少呢?我想還是回到風險/成本原則,也就是根據你所有的成本或資源,優先處理高風險的問題,我很少有看過有公司什麼資安都做到完的,就像我們不會在自己家裡弄個 108 道鎖來防小偷的意思一樣,當然這個決策只能由當事人自己做判斷,想聽 Sales 或外部顧問的意見? 你怎麼知道他們是在乎你的需求多一些還是在乎他的業績多一些?  你有看過 Sales 或顧問跑到你家好好研究你真正的需求在哪裡的經驗嗎? 就算對方肯,你敢讓他們來看嗎?!

F5 DataSafe 功能呢? 我個人認為這東西蠻適合哪種系統不是自己開發出來的公司,尤其是當你的公司有越多外包的網站越是這個樣子,由於有一些外包廠商可能根本也就沒維護合約了,或是要添加這個新的機制搞不好還比去買 F5 Advanced WAF 還更貴些,這時候就蠻適合來用 WAF 這東西,當然看是要買 F5 或其他廠牌的 WAF ,那又是另一個層次的決策了。

  • 對了 F5 Advanced WAF 還有另一個 Anti-Bot 功能似乎也常被來拿宣傳,只是目前沒時間研究,有接會再來研究下了

清潔用品推薦 – 適用於筆電、螢幕、鍵盤滑鼠、手機…

為什麼我們要寫這一篇呢? 相信每一位辦公室的工作者,不管是剛入社會的文書經辦還是位居高層的總字級人物,每天都不可或缺的工具就是你的電腦了,你用的可能是 PC、筆電或手機,不管哪一個用了每幾個禮拜之後上面都會沾滿了雙手分泌出來的油脂或手汗,加上環境中的落塵或吃飯喝湯喝飲料不小心濺出的污漬,總之就是髒啦,平常你都是怎麼清潔的呢?

話說我們公司有位同事前一陣子因緣際會之下飛到了菲律賓談案子,好死不死的他的筆電就在對方的辦公室裡 GG 了,原本應該是一副很難堪的下場的,沒想到對方的 MIS 竟然拆開了他的筆電,把內部風扇的灰塵清了清之後,那台經典小黑機又頭好壯壯的活了過來,但我同事除了驚艷於這點功力之外,那筆電回來時竟然是宛若新品般的乾淨絲滑(對,就是絲滑這個形容詞)。

於是乎我們 MIS 便開始了一段艱鉅的探訪任務:找到對方的清潔秘訣是什麼。最後,終於讓我們在中山北路的外勞專用舶來品店找到了這個東西:GreenCross 酒精 + 超細纖維布

2018-11-20 17.38.46

其實那塊超細纖維布我們是隨便買來的,想來任何一個牌子的都行,但是這罐菲律賓進口的 GreenCross 酒精就真的神奇了,價格不高,一罐可以用很久,接著就讓我們看看她的效果吧:

辦公室裡隨便撿一台看起來有點… 嗯的筆電來看看,雖然畫質不好,但可以看得出來 Dell Latitude 這類的上蓋材質很容易沾手汗變成這樣子,尤其在反光下就會有明顯的色斑和刮痕出現:

2018-11-24 16.33.14

開始隨便拿 GreenCross 倒在纖維布上亂擦一通,可以發現鍵盤 C 面處雖然非 A 面材質,但也是有些許油油的情況:

2018-11-24 16.34.26

擦完之後同一個角度再拍一張,可以明顯發現反光的色斑消失了許多,原本會容易因反光+油脂而容易看到的刮痕也不太容易看到了:

2018-11-24 16.36.13

鍵盤 C 面處也會有一樣的效果,看起來賞心悅目:

2018-11-24 16.36.28

老實說,如果只是有賞心悅目的話,那我以前常用的高科技泡棉沾水輕擦也是有同樣的效果,這罐清潔劑的重點是,擦完之後不但有股淡淡的讓人愉悅的香氣,而且摸起來的觸感上可以說是絲滑柔順,感覺上是上了一層看不見的保護膜一樣,原本很容易沾上手汗的材質感覺上也減緩了一些,吼~~~ 這真是我個人所見過的清潔工具中,效果最好的一種。

我原本還在想說會不會現在的清潔劑都那麼厲害了,剛好 MIS 之前也做了 AB Testing,所以我就拿著他們之前的對照組來試了一下,這應該是坊間買筆電常會附贈的清潔套裝組,搭配超細纖維擦拭布之後,我發現,其實這個清潔劑一樣可以有清潔的效果,只是清潔完畢之後,以 Latitude 的上蓋來說,摸起來的感覺是更接近出廠時的觸感 – 略微粗糙,但沒有絲滑的感覺,手汗也比較容易沾上,當然更沒有那種愉悅的香氣:

2018-11-24 16.13.38

最後拿來清潔了一下門口的電鈴,這電鈴放公司大門口按來按去的也好幾年了,從來沒清潔過,老實說,像是這麼髒的塑膠表面我會覺得還是拿高科技泡棉沾水輕輕擦拭的效果比較快且佳,用 GreenCross 雖然有酒精揮發快比較不怕傷到機器內部的優點,但擦起來就要費點力氣往覆好幾次,但最後的效果還是不錯的,這讓我想到一般的公司或家裡電話可能也都蠻適用於 GreenCross 這產品的,但這種門上的對講機因為使用時離鼻子比較遠,不像一般電話或鍵盤在使用時離鼻子比較近的關係,用 GreenCross 就顯現不出她的淡淡香氣:

總之這個 GreenCross 產品可以說是繼高科技泡棉之後,會讓我驚艷的第二個清潔用品了,各位有在幹 MIS 的朋友們,花點小錢讓你的客戶感受一下這樣子的清潔服務,相信一樣會讓許多客戶覺得驚艷的。

k8s in 5 minutes for Windows 10

前一陣子看了 William 大的 k8s in 5 minutes 之後,才發現原來要在本機跑 Kubernetes 不用再裝 minikube 了,尤其是在 Windows 環境下,要玩 k8s 還得要有特別的安裝方法,這讓我們這些用 Windows 當成日常環境的人總有些不得其門而入的感覺,現在 docker for desktop (下載時可能會叫做 Docker for Windows) 原生支援 k8s (本機版)之後,對於想要很快的看看 k8s 是啥的 Windows 使用者算是個很好的入門磚。

其實 5 分鐘所有的步驟都和 William 大寫的差距很小,只有小部分 Windows 環境下該注意的事項,但小弟資質駑頓,記性太差,還是寫清楚些以便日後參考:

  1. 要先啟用你 Windows 下的 Hyper-V (對 Windows 家用版就別試了)
  2. Docker for Windows 版 (現在也沒有所謂的 Edge 版本了)
  3. 如果你之前有裝過 minikube 的話,記得把 Kubernetes 的環境從 minikube 改成 Docker for Windows
    01
    02
  4. 在我的機器上 kubectl.exe 看來沒有加到搜尋路徑下,請自行加入 (我的安裝路徑在 C:\Program Files\Docker\Docker\resources\bin),不然就切換到該目錄下:
    C:\> cd C:\Program Files\Docker\Docker\resources\bin
  5. 裝個 k8s dashboard (非必須)
    C:\> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
  6. 把 proxy 跑起來,跑起來之後不能關掉這個視窗,得另外開一個命令列視窗出來繼續,
    C:\> kubectl proxy
    Starting to serve on 127.0.0.1:8001
    ...

    跑起來之後你可以用瀏覽器開下列網址存取 dashboard 來:

    http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
  7. 開另外一個命令視窗把範例裡的 echo-server 裝起來:
    C:\> kubectl apply -f https://raw.githubusercontent.com/coder-society/kubernetes-with-telepresence/master/echo-server/echo-server.yaml
  8. 最後一個步驟和 William 大的不一樣,由於 telepresence 這個工具在 Windows 下執行會有問題,所以用瀏覽器透過 proxy 的方式來測試這個 echo-server (其實這裡我卡了很久… 因為第一次用 k8s,才發現 William 大用了這個 telepresence,而 Windows 下這東西目前又跑不起來)
    http://localhost:8001/api/v1/namespaces/default/services/http:echo-server:/proxy/

    由於我們沒有指定 echo-server 的 namespace,所以這個服務會被放在 default namespace 下,與剛剛的 kube-dashboard 的 namespace 不同,一開始我搞錯也是卡很久

  9. 這個 echo-server 的功能看起來很簡單,就是 show 出目前是從哪台 server (k8s 的術語叫 pod) 跑出來的,你每次 refresh 一次,就會換一台 pod 來跑
    03
  10. 也可以看一下 k8s-dashboard,網址在剛剛啟用 proxy 之後有 show:http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
    04

同事 J 問我說這個 Docker for Windows 是不是開一個 Windows node 出來,仔細看了一下應該不是,它會在你的 Hyper-V 下起一個 Linux VM,所以要試 Windows node 的還是得等等其他人的文章了

05

06

其實昨天剛好有和一位 Google 的業務員聊到天,她自己認為 k8s 改版的速度實在是太快了,有些舊東西淘汰了、新東西加進來之類的都沒人知道。例如這一本台灣有的翻譯書:Kubernetes 使用指南,用到的是 k8s 1.0,裡頭講到的 Replication Controller 在新版本裡都改用 Deployment 和 Replica Set 了,現在去 Google 開一個 k8s cluster 也預設是 1.9.7 了,照著書來做大概只會覺得常常都對不上台詞吧。就算去翻對岸的簡體紀念版:Kubernetes 权威指南(纪念版),出版時也只是 cover 到 1.6 版,更遑論 k8s 官方的網站上已經放了 1.12 版讓人下載了,所以要學這個除了得花時間之外,手腳還得快一點,現在(2018/11/07)拿著最新的簡體中文書可能還對得上環境,可能再過幾個月又得另外找書或文章來學了。

RAVPower Type-C 充電器

上次買了個會導致我的 Dell 7280 降速充電的 PQI 之後,我又開始留意其它的 Type C 充電器,一開始先是找到了淘寶,賣家很直接的寫了這顆 RAVPower 的充電器雖然名目規格上只支援到 30W 的 Type C 輸出,但實際上卻可以跑到 20V * 2.25A = 45W,原本我就要直接下單給淘寶了,沒想到逛著逛著就逛到了美亞,除了底下評價的買家一樣證明了它可以輸出到 45W 的功率,而且美亞的白色規格也才賣 11.99 鎂,算了一下加上運費也才 500 台票出頭,比掏寶售價還便宜個一百多塊,於是就手滑了…

大概是坐船來的關係,過了兩個禮拜左右我才到手,應該是總價太低的關係沒課稅,包裝上沒什麼特別的,開箱之後有張笑臉的小紙張讓我想到 Anker 也是有一樣的紙張。

 

做工我覺得比 PQI 的好些,因為周圍不會有刮手的感覺

 

和 PQI 的比一下,其實兩個的 size 沒差多少,但標定重量 PQI 是 131g,而 RAVPOWER 則是 122.9g,不過 RAVPOWER 只有 2 埠,PQI 卻有 3 埠可用。

 

我手邊沒有可以量 20V 輸出的測量器具可以測試,不過趁著今天出差把筆電的電用到了 50% 左右的時候,試了一下會不會降頻,答案是不會,表示這顆 Type C 充電器至少可以輸出到 35W 以上。

2018-05-31_191515

打完收工,看來以後我會隨身放電腦包的會是這顆充電器了,因為我不想以後去客戶那邊 Demo 到一半時降速到跑不動程式,但… 那顆 PQI 的誰要接手啊。 😦

  • 2018/11/08 更新,今天發現大瓦數的 PD 充電器已經很常見了,PChome 購物上面就一堆,也不用特別去海淘

CloudFlare & Google Cloud CDN

大概前兩天吧,為了測試 Google Computer Engineer (以下簡稱 GCE) 到底好不好用,網速到底夠不夠快,我們小 J 弄了台 VM 出來測試,當時我們就對 Google Cloud CDN 表現出來的速度水準驚艷不已,不管是拿 KeyCDN Tool 來測試全球速度,拿 Webkaka站長工具來測大陸速度,加上了 Google CDN 的測速結果都比單純使用 Google Load Balance 或僅用 GCE 的狀況下要來得快很多,可惜當時只是把幾個測試結果排在一起比較,並沒有截圖留念做個證明。
* 後來我們才發現當時所放上的 Google Cloud CDN之所以快,主因是因為有一起啟用了 Anycast IP,所以 Anycast IP 才是關鍵點,細節再請看以下的測試

CloudFlare 是另外一個我很愛的 CDN Provider,價格便宜、防攻擊,後台簡單好用,免費 DNS,又常會發表技術文在他們自己的部落格上讓人觀摩,只可惜不管是 Free Plan、Pro Plan 或是 Business Plan,速度表現上和其它商用的 CDN 來說都是差強人意的,有時候不錯,有時候就很慢,至於 Enterprise Plan 我個人是沒試過,聽說是和其它 CDN 一樣可以提供某種程度的客制化,例如 best routing 一類的,希望將來有機會用到。

雖然說 CloudFlare 通常是差強人意,但每次看到他們在部落格上 寫了些黑科技,就忍不住想要嘗試一下,像是 ArgoRailgun,兩種都有網友提到說他們的測試結果不錯,有人說 Railgun 比 Argo 好,也有人測試之後說 Argo 不錯,所以今天就讓我們自己來證明一下。

我大致上的基本架構,也是目前跑在 Internet 上的配置都是 GCE 為主,然後依序加上 Google Load Balance with Anycast IP、Google CDN、CloudFlare CDN 與 CloudFlare Argo 上去,看看哪一種配置跑出來的結果最好,這次的測試我只用 KeyCDN Tool 來測試,畢竟我們網站主要的使用者並非中國用戶,KeyCDN Tool 也相對簡單穩定,不會有其它工具有時候開不到的問題。

以下的測試結果因為 KeyCDN Tool 僅有 TTFB (Time To First Byte) 的關係,所以也就只能以這個數值為參考。

SpeedTest

 

結果… 最好的狀況就是 Google Anycast IP + GCE 的合體,由於我拿來測試的網站基本上全是動態內容,看來有沒有掛上 Google CDN 並沒有顯著的差異。以上結果就是說:全部採用 Google 的服務,其它什麼 CloudFlare + GCE ,或 CloudFlare + Argo + GCE 什麼挖貴的,全部都比不上 Google Anycast IP 的數字,拿掉了 Anycast IP 之後,速度就是上不去,跑幾次都是一樣。說實在的,這對於常常在讚嘆 CloudFlare 部落格的我來說,這實在是太打臉了,和什麼廣告都沒打,後台介面又整個陽春的 Google 比起來,在速度上 Google 實在是佔了太多優勢了。後來想一想,Google 花大錢在各地架海纜果然不是做白工的,有自有大頻寬海纜這種基礎建設大概就贏八成了。

當然 CloudFlare 有其 DDoS Mitigation 的功用在,也提供免費的 SSL 證書 (Google Cloud CDN 也有),但不管有沒有用 Argo,只要是上了 SSL 的網站,速度一律再下降一個檔次,所以我索性也就不紀錄了,放了也是難看。

最後要註明的是,我這次測試的 Argo 並非 CloudFlare 的完全版,完全版的 Argo 需要安裝一個 Argo Tunnel 的程式在 Server 端,讓 Server 可以走最好的路徑到 CloudFlare 機房,接著就看有沒有機會再去測試他了,不過我的下一個測試目標應該是號稱有機會可以節省動態網站頻寬 10 倍的 Railgun,Argo Tnnel… 再等等吧。

Dell Latitude 7390 開箱

早在之前的 New XPS 13 在手時,就一直覺得這麼好的窄邊框設計怎麼不放在 Latitude 系列上,變成 New XPS 13 的優點變成窄邊框螢幕,而 Latitude 則是有完整的外接埠(HDMI, 網路),兩個井水不犯河水,看你喜歡哪一個。

一直到去年的 7380 出現,才讓我眼睛一亮,原本一直明示暗示我們 MIS 伙伴可以買這個,但沒想到那傢伙不知道是怕麻煩還是懶得看,還是買了很多 7480 進來,一直到最近公司的 NB 汰換週期又到了,才有這個機會碰到這台,原本下單的是 7380 ,但運氣不錯的剛好遇到 Dell 改版,所以拿到手的就變成 7390 嘍。

01

IMAG2379

一樣是超簡潔的包裝,反正這種箱子留在公司也是佔地方。

IMAG2380

附贈的還是 65W 的充電器,雖然我喜歡他的大頭,因為和以前的可以相容,但 New XPS 13 可以用比較小巧的 45W 充電器,沒理由沒獨顯的 Latitude 不能用吧?

打開來驗明一下正身,背後的標籤的確是寫著 7390,只是,整台機器和我的 7280 怎麼看起來一樣?

IMAG2383

打開來看就發現不一樣的地方了,窄邊框!!!

IMAG2384

近一點看,感覺上方為了要保留視訊鏡頭,上方那個框的間距並不是很窄,和左右兩邊的差距有點大,感覺不是挺搭,難怪 New XPS 13 要把鏡頭往下方擺,既使被人笑說是照鼻孔。唉,有一好沒兩好。

IMAG2385IMAG2386

左右兩邊的 I/O,其實和 7280 一模一樣

04

上方是我的 7280 (指紋很多傷眼請見諒),下方是 7390

05

左 7280,右 7390

06

左 7280,右 7390,其實可以看得出來這兩台除了螢幕之外,其餘的外觀是完全的一樣,但神奇的是,7390 (7380也是)官方的重量是 1.17kg,而 7280 則是 1.18kg,這和我與幾位同事實地手持的手感一致,就是 7390 的確是輕了一點點。

IMAG2391

最後一張就讓我把傳統邊框的 7280 和窄邊框的 7390 放在一起對照一下,有感覺大一點嗎?從訂價看窄邊框的代價是 100 鎂,我個人覺得是很值得,也推薦給網友參考。