I T 練肖喂

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 通常是差強人意，但每次看到他們在部落格上寫了些黑科技，就忍不住想要嘗試一下，像是 Argo 和 Railgun，兩種都有網友提到說他們的測試結果不錯，有人說 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 嘍。

IMAG2379

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

IMAG2380

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

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

IMAG2383

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

IMAG2384

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

IMAG2385 IMAG2386

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

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

左 7280，右 7390

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

IMAG2391

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

PQI Smart 41W i-Charger PD 充電器開箱

* 警告：日前發現用這顆充電器來充我的 Dell 7280 時，如果電池容量在 95% 以下時，CPU 時脈會被鎖在最低速以致於太慢太難操作(看起來是降低時脈換來充電？)，等到電池充滿到 95% 以上時會回到正常，想買這顆充電器的請注意這個可能的狀況，這顆充電器還是只適合筆電關機充或看文章時充，所以我後來從美亞買了一顆可輸出 45W 的充電器，請移駕這裡。

今天為什麼特別要來寫這一篇看似葉佩雯的開箱呢？因為自從我之前入手了 New XPS 13 開始，就一直想找個 Type C with PD 的多埠充電器，這樣子不管是在外移動或是出差時，包包裡就可以少一個充電器的重量，然而之前只看過 PowerPort+ 5 USB-C PD 充電器，212g 左右的重量比我主力使用的 Acbel 萬用筆電充電器 229g 沒輕太多，還比我另一顆 Amacrox Uone 的 165g (含線) 還重，加上我一般狀況下也用不到 5 port 來充電，所以就遲遲未入手。一直到前幾天看到這顆東西：

2018-03-22 13.00.02

3 port，131g 的重量，價格也 OK (蝦皮上有不到 1,000 含運的)，過了幾天後這東西就到了我桌上了，包裝上寫這東西總輸出可以到是 41W，其中 Type C 的輸出最高 14.5V 2A = 29W，剩下兩個 USB Type A 輸出總和是 5V 2.4A = 12W，看來是剛好堪用。

2018-03-22 13.00.34

內容物很簡單就是一顆白豆腐，連一條線都沒附，幸好我之前就買了條紫米的雙 Type C 充電傳輸線，但這也表示這顆白豆腐就重 131g 了。

上面的標籤寫的是 PQI Japan 株式會社在中國生產的 (PQI 不是台灣公司嗎？)，查了一下日本的牌價是 3,980 日圓，所以我買的價格還好。不過這顆充電器的做工有點差強人意，我認為還比小米的 4 Port 充電器質感還差一點，四周斜邊摸起來略為割手，但不到會割傷的程度，那些標註規格的小字看起來也有一點點蓋歪。不過比較重要的安規倒是印了五種，雖然廣告上不像一些他廠一樣寫了什麼幾種保護，xx 晶片之類的，有通過五種安規倒是比較實際些。

單充電器的重量用我的廚房秤量出來是 135g，比規格上的 131g 多了 4g，有可能是這秤不準。加上 Type C 線材後則是 168g，比我之前買的 Amacrox Uone 還多了 3g 讓我有點小失望。但想想這可是能讓我少帶一顆充電器的好物時，就覺得這 3g 還 OK 了。

2018-03-22 13.04.36

配上號稱能走 3A 電流的 150cm 紫米傳輸充電線，和 Macbook 充電器一樣會干涉這種垂直多孔插座的其它插座孔…

2018-03-22_130757

我的 Dell E7280 竟然給我跳出這個訊息，說只有 35W 以上的供電才能保證一定往電池充，這點我還挺納悶，之前插過 QC 2.0 充電器時系統是跳出要 27W 所以不能用，而現在則是說要 35W，不過用了一下之後發現 Windows 右下角仍然顯示充電中，事後我也嘗試完全關機，他也的確充得進去，所以這顆充電器在一般出差或外出時小用還是可以的，但是要長時間在外執行重量級的程式時得要擔心力有未歹了。另外要補充的一點是，差著這顆充電器開機時，E7280 的 Bios 還會再給一個警告訊息，告訴你這個充電器不合 35W 的規，邊用邊充到時候越用電量越低的話你可別怪我沒通知你之類的意思 blah blah…..

2018-03-22 13.06.12

拿同一條 Type C 線來充我的 HTC U11 手機時，會顯示「已連接快速充電器」，雖然規格中這顆是沒有支援 QC 2.0 or 3.0 的，由於我手上也沒有偵測電量的測試器，所以也不清楚這個快速是跑在哪一檔 (這顆支援三種 PD 輸出：5V/3A ,9V/3A ,14.5V/2A) ，看網友有跑在 9V 過，而且沒聽過哪支手機能用 14.5V 這麼大的電壓充，所以只能不負責任推測是跑 9V 在充電。

後來也拿去充看看同事的 Macbook Pro 13 with TB，雖然沒截圖但是 Mac 上是顯示充電中的，大家也都知道 Macbook (12吋那台) 就是吃 29W 的充電器，但 Macbook Pro 13 標配的充電器則是 61W，想來也是只能期望帶著這顆充電器不會遇到要長時間跑程式的狀況了。

現在我正好插著這顆充電器對我開機著的 7280 充電中，目前電池仍有 92% 的電，但系統預估要 1hr 31mins 才能充飽，當然目前 Dell 的 Power Manager 因為判定有接充電器所以系統是跑在 Better Performance 模式下，各位看官可以自己參考一下這顆到底適不適合你入手了。

補充說明一下，剛打完要 1hr 31mins 充飽電這一點，當我發表文章時卻發現 7280 的電池已經充飽了，實際上 Dell Power Manager 判定要 1 小時半的，但實際上 10 分鐘就把那 8% 充完畢了。
剛剛看還有顆 Innergie PowerJoy 30C 的才 96g，但只提供 2 port，也許網友也會有興趣
剛剛加映一顆可以不降頻充 7280 的 Ravpower Type C充電器，請看這裡

Project Honolulu 是個免錢又大碗的東西嗎?

前幾週聽了 Weithenn 大介紹的 Windows S2D 和 Docker 之後，對於他提到的微軟免費工具 – Project Honolulu 很感興趣，聽來是號稱 MS System Center 的免費版本，這立刻讓我腦海中想到了諸如自動化升級、VM服務自助化或是什麼工作流程自動化一類的，心裡想說微軟終於是佛心來著，便馬上填了些資料下載來玩。

下載和安裝本身並不複雜，雖然它有三種部署的方式，但由於我的目的只是看看這東西有什麼功能，所以變直接安裝在我的 Windows 10 NB 上，這部分的安裝過程沒什麼困難性，一下子也就完成了。

倒是準備要被 Project Honolulu 「管控」的機器還有些特殊需求，除了至少要是 Windows 2012 R2 以上的版本外，還得裝上 Windows Management Framework (WMF) 5.0 以上的版本(網站上給的安裝連結是 WMF 5.1)，由於安裝完畢之後需要重開機，如果你的環境剛好沒有符合需求的機器，又不能輕易重開機的話，可能會跑不下去。安裝 WMF 5.1 的時候有個小插曲，就是我找了三台 Windows 2012 R2 ，每一台都告訴我這個安裝檔並不試用於我的環境，最後搞了老半天，原來我一直下載到的是一個叫做 W2K12-KB3191565-x64.msu 的安裝檔，但試用於 Windows 2012 R2 的安裝檔是叫做 Win8.1AndW2K12R2-KB3191564-x64.msu，這種蠢事我也是 Google 之後才發現的，顯然微軟這種命名方式騙到我這種蠢蛋了…

Project Honolulu 會在本機裡裝個小型的 Web server ，裝好之後直接點開始功能表就會把網頁給打開了，一打開來，我優先去點擊的這個功能：

嗯，Windows Update，怎麼這麼熟悉？按下 Install Updates 按鈕之後跳到下個頁面：

嗯… 還是很熟悉的畫面… 什麼？！這該不會就是 Project Honolulu 的功能吧？完整的把本機上的系統管理功能、設定功能給搬到 Web 上讓我們可以「遠端 GUI」作業，真的是這樣子嗎？讓我再擷取幾個畫面看看：

這是我自己 NB 的監控畫面，這… 不就是工作管理員

看得出來可以管理四種標的，後面的 Faliover Cluster 和 Hyper-Converged Cluster 我目前沒有，選個 Server Manager 看看：

要檢視某一台 Server 之前，要先等系統跑一下子

設定畫面，原本以為可以在這裡設定報警條件的，結果原來只能設定環境變數

Event viewer ？！事件檢視器，一模一樣勒

防火牆設定，就是防火牆設定

這個稍微有新意一點，Web 版本的遠端 Power Shell，有了這個就表示什麼功能都可以自己刻了吧？

放大絕了啦，Web 版的遠端桌面，Project Honolulu 還有什麼做不到的？

唯一的一點點小缺憾是目前沒有在 Project Honolulu 裡看到 IIS Management 的操作功能，不知道是還在製作中或是沒打算做(反正 Power Shell 都可以做到)，除了 IIS 之外，其實還有許多 Windows Server 的管理功能沒有被實做上去，這篇 FAQ 裡有完整的支援/不支援清單。

所以簡單做個總結，Project Honolulu 像是個 Remote Desktop Manager + Computer Manager 的綜合升級版，其中一種部署方式是可以把 Server 部署在跳板機上，然後系統管理員便可以從真正的遠端透過瀏覽器進行系統管理。由於可以事先把受管理的 Server 清單建在系統上，機器多的時候要找也是方便了一點，所以要說是簡化了系統管理程序也未嘗不可啦，不過要說是像 System Center 一樣能簡化資料中心的管理嘛，倒是差了那麼一大截。唯一可以理解的是：Project Honolulu 所依賴的底層 WMP 5.1 應該已經可以含括到 Windows 系統管理的許多功能了，所以除了微軟自己的 System Center 之外，應該也可以期待會有 3rd party 開發出諸如自助化服務網站的功能出來，或是自己想辦法刻出來？

目前我使用的 TP 版本是 1711，雖然我也只是玩一玩試一試，但可以感覺得出來這東西並沒有明顯的狀況或當機之類的問題，應該可以算是很成熟的東西了，只是我之前對它的期望太高，試用之後不免有些空虛就是了。

又一個 Wifi AP 問題

由於~~老闆做興趣的~~公司多元化發展，所以跑去外地開了間旅館，一切都完工開張之後，就開始是我們的夢魘了，說是夢魘也算一半是自己造的業，當初在幫忙審弱電規格時，想說只是間不大的旅館，看到兩家廠商都提出用 DrayTek 的 Fat AP + 中央控管解決方案後，就覺得這東西可能還可以，也傻傻的以為負責統包的「廠商」會用心的幫忙解決一切的問題，結果… 廠商也就只是裝好而已，其它的也是能推就推，加上我們自己也不熟悉這個廠牌，中間的過程這邊就不抱怨了，在一步一步的試錯之後，我們今天又遇到一個麻煩事。

老闆說：那個那個 908 號房的訊號很差，無線網路還是很不好啊，到底解決了沒有？

幸好今天我們的小銳同事今天有過去開會，趕緊拿起電話急扣：快幫我去 908 號房試試，其實也幸好那房間現在沒住人，小銳同事開了門就跑進去看訊號強度。

報告報告，訊號看起來都還不錯哩，我手機上看來都有 3 格 (其實我不太確定他是拿什麼軟體看的，我腦補滿格是 5 格)。

小銳這個人其實在技術上也是挺細心的，一下子用 LINE 打給我做走動測試，一下子跑 SpeedTest，終於給了我一個 AHA ：我知道哪裡有問題了！就是這個角落，小銳說他一走到這，和我的 LINE 通話就會斷斷續續。靠，這種土炮測試竟然比那些什麼 Wifi 強度 App 要來得快速有效還自帶團隊合作感，趕快繼續土炮下去，ㄟㄟㄟ，那個小銳你就一邊重複念 1~10，一邊走動，我一有聽不到的的時候就叫你停，然後看是在幾號…

AP1

測著測著小銳就想到幾週前，由於飯店在遠方，我們靠飯店那些非 IT 專業的工作人員蒐集到的問題描述又很亂：有人說連不上網路，也有人說網路速度慢，所以我們便在不同的樓層上對 AP 做上不同的設定，希望下次再來時可以藉由這些實驗組對照出還剩下的問題。

小銳說，這個樓層就是有做 2.4G + 5G 的雙頻設定，而且開了所謂的 Band Steering 功能，AP 上對這個功能的描述是：當 5G 訊號夠強時，AP 會強迫客戶端從 2.4G 跳到 5G 去。

只是沒想到，這個 5G 訊號的穿透能力看來不甚好，既使「訊號上」看起來還可以，但實際上的傳輸就是會出問題，嗯… 至少我們打 LINE 電話就出問題了。有了這個假設之後，我們就趕緊把這層樓的 5G 實驗組給拿掉，讓他只跑 2.4G 訊號，接著再讓小銳出動進行走動式土炮 LINE 通話測試，果不其然，一切就順順利利，趕快和老闆回報問題解決。

說實在的，對於 Wifi 問題我還真的沒啥辦法，又不是程式、系統或資料庫可以去翻出來看，訊號的這東西我是完全沒輒，你去問所謂的專家嘛，感覺就是叫你買 Cisco, Aruba 好像一切就解決了，你一叫他保證時他也不敢掛保證。這次大概是我處理各種 Wifi 問題以來「相對」的最有科學根據的一次吧，希望這樣子的運氣可以持續下去啊，不然三不五時的要開車跑遠地去處理也是既費時又費力。

Unifi AP 的升級

先開宗明義來說，其實不是什麼很難的東西，大致上來說，對於這類 ThinAP 的管理上，你得要注意 Controller 和 AP 之間誰負責什麼東西，才會比較容易知道問題出在哪。

以我今天遇到的問題來說，其實就只單純的是看到 Controller 的 GUI 上顯示了有 firmware 可以升級，按下升級鍵之後，這個 Controller 的 GUI 也是煞有其事的在那裡跑了很久，最後… 版本號碼還是顯示一樣，這問題與其說是今天發現的，倒不如說是已經發現很久了，只是之前一直沒有動機去升級它，今天是因為看到有幾位 user 反應有 Wifi 的連線問題，想說目前的版號距離上一次也已經快一年了，看 Change log 裡也滿滿的都是我看不懂的 bug fix，所以選日不如撞日，就試著解解看吧。

爬了一些論壇文章，症狀雖然都是升級不上去，但是有人教你用 GUI 上的自定義升級，有人教你 ssh 進 AP 自己下指令去 Controller 抓 firmware 下來，我甚至還跑到 AP 裡頭去看 log，但是都沒用，連 log 都沒看到任何錯誤。最後我是看到有個人提醒說要在 AP 上校時，這時候心血來朝，試著去 AP 上 ping ping 看隨便一個網址… Bingo！

原來是因為我們的 AP 由於是跑單純的 bridge mode，Controller 與 AP 之間的溝通也是透過 IP 而非 Domain name，所以當初設定的同事並沒有在 AP 上設定 DNS resolver，動手加進去之後，就可以順利由 GUI 上簡單的升級了。

在這個案例中，有趣的是由於 Controller 上一直顯示著可以升級 firmware，以致於我從沒想過實際的升級程序是 Controller 叫 AP 自己去抓 firmware 下來升級，加上這個 Controller 的 GUI 上也沒有正確 capture 這個錯誤出來，所以自己卡關了很久。這個升級雖然只是個不起眼的小事，卻解決了我心中卡很久的一口痰，還是覺得爽。

比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞，才發現原來這東西這麼神，2700 倍的傳輸率，佇列延遲減少 25 倍，隨手翻了下網路上的部落格，沒想到有那麼浮誇的說法證明：下載從 84K/s 變成 3.9M/s，這立刻引起我的好奇心，找到了 Google 自己的部落格說明，原來是長久以來使用的 TCP 壅塞控制演算法有點笨，遇到有 packet loss 的狀況時，就會以比較保守的方式來傳遞接下來的封包，而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題，整個示意圖就如下所示：

* Source

文中也特別拿了幾個國家為例子，說明在應用了 TCP BBR 之後，YouTube 的表現情形，不看還好，一看之下，沒想到 Google 也這麼浮誇寫實，YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上，這讓我突然想到以前公司在進行某個網路直播專案時，那個爛 4G 網路讓我們驗收時吃了很多苦頭，所以我也來做個浮誇的測試好了。不過因為一來我很懶，二來也沒那個預算搭建回當初專案的原始架構，所以以下浮誇的測試只在我的本機上實驗。

實驗環境 (都在同一台機器裡)：

NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome

實驗方法：

先以 Kernel 2.6.32-696.6.3 直接測試，擷取螢幕看直播視訊延遲
以 clumsy 加上 inbound & outbound 各 50ms 的延遲，並隨機 drop 10% 的封包
等個幾秒，擷取螢幕看直播視訊延遲
停止 clumsy，等個幾秒，擷取螢幕看直播視訊延遲
升級 Kernel 為 4.13.0-0.rc1，重複步驟 1~4
* 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面，所以測試畫面中會看到 Firefox

實驗結果：

沒 TCP BBR，不啟用 clumsy，延遲大概 3 秒
沒 TCP BBR，啟用 clumsy，稍等一下，延遲變為 13 秒，實測時這個延遲會迅速擴大，最差的狀況是影像會停掉
沒 TCP BBR，把 clumsy 關掉，稍等一下，延遲回到 5 秒左右
有 TCP BBR ，不啟用 clumsy，延遲大概 2-3 秒，其實和沒 BBR 時差不多，這畫面看起來延遲只有 2 秒應該只是個測試誤差
有 TCP BBR，啟用 clumsy，稍等一下，延遲變為 4 秒
不信邪，再等一等，有 TCP BBR，啟用 clumsy，延遲還是維持 4 秒左右
恢復原狀，有 TCP BBR，不啟用 clumsy，延遲還是維持 4 秒不動

總結來看，這個 TCP BBR 還真的神，在高延遲且掉包的網路上，在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現，安裝的方法我就不特別提了，網路上隨便 google 都一堆，不過還是要提醒大家一下，再好的東西還是得先測試才能上正式環境，免得哪個不小心你就踩了坑了都不知道。

BBR Summary

一個很糟糕的 gmail 問題終於被修正了

認識我的人都知道，我在 gmail 一開始 beta 時就有幸拿到了邀請函，並且申請了一個和我英文名字一模一樣的 gmail 帳號，而我老婆的 gmail 帳號稍微差一點，有帶她的中文姓氏，我記得是因為當時 gmail 註冊的規則是不允許 5 個字以下 (含 5 個字) 的帳號名稱，且不能是常見的美國名字 (或單字，我猜)，而我的英文名字剛好是歐洲系的，所以一直以來我都對於能擁有這個帳號是爽在心理，偶而還拿出來炫耀一下。

但是事情總是不會那麼幸福美滿的，不知道從哪一天開始，我的 gmail 就充斥著一堆的垃圾信，講到這裡大家可能會覺得很怪，gmail 檔垃圾信不是出名的嗎？就算是我的 gmail 有個好名字，也沒有什麼關連性吧？

是的，gmail 的確是檔垃圾信檔得很好，但是，不是垃圾信的垃圾信呢？

啥，你在共啥小？！什麼叫不是垃圾信的垃圾信？

其實就是那種別人拿你的 gmail 帳號去註冊某個網路服務，之後那個服務就一直狂發信給你的一種狀況，根據我看了那麼多不是垃圾信的垃圾信的經驗得知，這種狀況一般可以歸類成兩種

真的是不小心寫錯 email 地址的：不管他是記姓不好的三寶、少根筋而打錯字還是管他阿媽什麼挖貴原因的，反正就是寫錯了，為啥我會知道是寫錯的呢？因為我有收到各種各國的 EC 網站送貨通知，而且錢都已經付了，在這裡還是要歌頌一下 Google，幸好他 gmail 內建有翻譯功能，不然我還真看不懂這些垃圾信
故意寫錯的：從這幾年收些垃圾信的經驗裡，還真的有很多網路服務是不驗證 email 信箱是不是你的 (請注意我現在已經是以全球性的世界觀來講這件事)，也就是你申請註冊之後，他就當你註冊成功了，所以有可能是有人亂用我的 gmail 帳號註冊，也不排除這是一種另類的廣告信手法。其實我猜 email 要認證這件事情應該是這幾年才有的，因為我的 Apple ID 其實早就被人申請好了，幾年前的某一天當我要申請 Apple ID 時，我做的事情其實是去按 forget password，而不是新申請一個，這類事情我至少經歷了三四次有吧，都是別人在多年前不流行 email 驗證時先幫我申請好的帳號，然後我再去用 forget password 給拿回來。而目前呢？剛剛翻了一下，我的信箱收件夾裡還躺著 4 封 Instagram 的申請確認信，其中 3 封是英文的，1 封是印尼文，當然我是個還沒用 Instagram 的土包子，這四封驗證信都不是我自己申請的。

那上面這些講了落落長，都不是 gmail 的糟糕問題啊？你到底在講啥？！

其實是 gmail 有個功能叫「備用信箱」，每個帳號都可以設定一個備用信箱，一旦你忘記自己信箱的密碼時，又沒有設定手機門耗時，就可以記封忘記密碼的信到你設定的備用信箱來進行重置密碼的動作。但是… gmail 這功能以前可是不需要驗證的，所以你設定了就是設定了，他也不會管你是不是有打錯字還是記錯了，所以我長久以來，就是會收到各國語言的「密碼重置信」，這時候我就得記得去按「請把我的 gmail 信箱從那傢伙的備用信箱移除」，非常的惱人，一直到今天，gmail 終於做出了一個劃時代的更新(對我而言啦)：

2017-07-28_010342

靠你終於改了啊，雖然我的帳號還是常收到不明來由的垃圾信，但連 google 都發垃圾信給我我就很不爽，雖然我的 gmail 因容量還沒到上限沒付過錢，但我可是 Android 的愛好者，GCE 也付了幾次小錢，平常也讓你抓我的 GPS 資訊讓你偵測車流量，終於，這次你解決了我的一個困擾。

其實我猜測有類似問題的人應該也不少，例如我公司的 email 並不好記，但偶而也是有類似的垃圾信出現，我會猜測是一種另類的廣告信手法，真是希望那些垃圾信名單機構可以增加一種黑名單，就是當你這個網站拿 email 註冊而不需驗證時，提出證明就可以列入這個黑名單內，然後不管是 gmail 或自己管理的 email server 就可以設定拒絕這類網站寄出的信件，才能杜絕這些惱人的垃圾信。

玩一下 Google Compute Engine 要花很多錢嗎？

雖然身為一個 IT 人，也知道這一行要與時俱進不然就被淘汰的道理，但是我個人對於「在雲端上花錢」這件事情的態度算是偏向保守的那一派，像是 LINE Pay 已經出來半年了，我是為了貪那繳稅的回饋金才去辦卡且綁定了我的 LINE 帳號，Google Play 上就算有需要綁定過信用卡，也是用完之後就移掉，不然我自己會想像被他亂收錢。

這次之所以會想要在 GCE 上花錢，是因為看了某個對岸網友的文章，發現 Google 竟然直接在他的 GCE 上提供 Anycast IP + Global Load Balancer + CDN 的服務，因為這實在是太狂了，所以我忍不住就打破了自己的的風險規則，跑去把我的信用卡放上去。

我測試的東西也就是 Anycast IP –> With CDN –> Load Balancer –> 一台台灣 VM + 一台新加坡 VM 這樣子的架構，測試之前先在我自己電腦上的 VM 跑了一次，並且把安裝與設定步驟記錄了下來，所以去 Google 上開機器時，除了幾個 Google 自己的設定需要實驗多花了點時間之外，大致上可以說是沒幾個小時就做完相關的設定工作，然後就開始測試了。之後就放那邊放了兩天，端午節之前把 Anycast IP, CDN, Load Balancer 及新加坡機器關掉，只留下台灣這台 VM 給同事測試用 (對，我實際上的需求並沒有一定得要用 Anycast IP，只是拿來試試看功能而已)，這樣子我一共花了多少錢呢？才 US$1.96

而且 Google 也提供了一個預算管制的功能，當所花的錢超過你設定的預算時，就會發警示信出來。因為我拿來玩 GCE 的帳號就是我平常在用的 Google 帳號，也綁了我的 Android 手機，所以這功能讓我很安心的繼續用下去。

前一陣子不知道是哪位臉書上的心得，說是微軟 Azure 要和 Amazon AWS 或 Google GCE 對打還是走得很辛苦的。對照一下這幾年來看到 Google 在做的事情：Google 自建海纜、GCE、Anycast IP on GCE、Google CDN (如果 Google 要把他們在世界各個 ISP 放的 Google Global Cache 也拿來做 CDN 加速的話，那就更恐怖了)，可以看到 Google 要做而且已經快做到的是「世界」的 IT Infrastructure – 全世界的中華電信、全世界的 Hinet，這意思是什麼呢？如果你今天只想做台灣的網站也就算了，如果你是想搞跨國的網路應用(電子商務、遊戲、社群、直播…)，以後你也不用多想了，就直接放 Google 上就好了，如同幾年前的台灣一樣，大家想搞網路、搞遊戲，機房鐵定要選中華電信、專線一定得拉 Hinet，因為全台灣的使用者幾乎都是用 Hinet，想不接 Hinet 線路就是要讓使用者 lag 爆。這種事情以後就會反過來，大家要在全球佈局的話首選就會是 Google，因為最簡單速度又最快。

所以，學學這些 Public Cloud 的使用經驗看來就是未來 IT 人的必備技能，而且搞不好還比去學什麼 Server 安裝或 Cisco 設備操作要來得基本且必要，要練習這些東西很花錢嗎？你要練 Server 安裝、系統管理之類的可能要去買台機器或借個環境才能操作，想練網路我看很多人會花個幾千塊去網路上買二手設備來練習，但是想練 Google Public Cloud？以我這次的例子來說，只要 1.96 鎂就好，可能比很多人一天的通勤費用還便宜些，好東西，不買嗎？