[前言] 寫這篇文章前, 我先跟 circle.tw 的編輯告解, 因為當時他們找我時, 我說要寫一篇不同的觀點文章, 就是這一篇, 因此想說多搜集一點資料再來寫, 但當看到昨天 "NCC發言人虞孝成:影響網速原因有80個 台網速並不差" 這篇文章後, 我覺得已經不能再拖了, 不然又是三四個月又過去了.
小弟不才, 雖然沒辦法像許多人把事情說得天花亂墜, 但至少勉強有一個專才, 就是高有效性與效能調校, 而我知道這是一個看起來簡單, 但事實上相當複雜的事, 尤其最近討論的 "網路效率" 的事, 就職業經驗知道這件事, 事實上並沒有那麼簡單.
說到網路, 大家很喜歡拿 ISO 的 OSI 七層來討論, 事實上網路在實作上, 並沒有真的切割到如此 "mutually exclusive" 的七層, 但換個觀點, 網路也不只有七層, 甚至切割下去是相當多層, 想要知道一件事的效能瓶頸, 要了解每一個層面的效率極限, 而這個環節比想像中還要複雜.
但再複雜, 身為一個工程師不可能不會去想要解決與挑戰, 甚至實務上不是只有在那邊亂想亂猜, 要去一層層的建立每一段的 "Monitor Agent" 監看系統, 然後將之串起來, 慢慢的發現問題在那邊去解決, 只是就經驗來看, 真正的問題往往發生在沒有顧及到的層面, 因為若有注意到的話自然會去解決, 但問題還是發生在環節內, 只要再去切割更細就好, 而為了避免有環節沒考慮到, 最重要的監看系統就是: "事實結果" 的資料搜集, 也就是從上到下的整段使用記錄.
網路效率真的問題很複雜, 事實上我在三個月前是想幫政府說話, 因為有些問題不是政府能夠解決的, 須要財團與使用者大家一起努力, 但最近看到政府與財團出面的一昧指責使用者, 我還真不知道這個戲碼到底在演甚麼?
為了來了解台灣網路速度為甚麼會這樣, 我們來做個大項目, 及小項目的切割好了, 至少來做個 Divided and Conquered 的了解, 讓大家知道問題點:
大項1. 使用者端電腦: 主要的子項目有瀏灠器, 作業系統, 硬體設備, 執行環境.
大項2. 使用者端網路: 包含使用者家中的環境, 大樓的環境, 到局端的設備.
大項3. 局端到ISP: 使用者到基地台, 基地台到 ISP, 或是中繼站到 ISP之間的環境.
大項4. ISP到伺服器: ISP 之間的串接, ISP 的設備, 最後到的 Server連結.
大項5. 伺服器端的電腦: 也包含網路設備, 伺服器應體, 作業系統及應用程式與專用程式.
大項6. 背後串接的系統: 系統背後之資料庫, API 之間的串接, 硬體之間的串接
這大項中大約每一個有 3~5 個小項, 每一個小項大約有 5~8 個條目, 這 5 個條目中要注意到的 Monitor Point 監控點有 10~20 個, 因此真的要找到問題的話, 要注意的地方大約有 250~350 個原因, 這還不包含每一個模組內部所使用的物件.
因此大家可以知道要找到問題的原因是沒這麼簡單, 只是若問題無法解決, 那要網管做甚麼, 那要效能調校做甚麼, 我當然就沒工作可以養家活口, 畢竟這是個專業, 但因為專業就拿來嚇人是不道德的, 畢竟事實就是事實.
即使大家最熟悉的瀏灠器, 這其中須要解決的問題就很多了, 包含那種瀏灠器, 那種版本, 有用那些外掛, 有那些設定, 其中外掛的項目可能就不只 10 種了, 更何況去確認真正的問題細節, 而網路設備的規格數十項, 每一項都有不只一項的細節, 一個有實務經驗的網管/系統調校者知道魔鬼就是在細節中, 想要靠一張嘴解決問題雖然說是誰都可以做, 但裏面的技術是相當迷人的.. (嗯, 我扯遠了~~~)
雖然可能只有訓練有素的狗才能夠嗅出問題點在那, 但問題點是大家都可以感覺得到, 尤其這是網路的真實面, 因為網路上的所有行為都有 "原始記錄" :
"網路的真實就是可以搜集最原始的資料去分析來去看真實面, 而不只是靠其他的 Benchmark 基準來去說就算的!"
也就說即使不要管這些不只 80 種而是超過 200 種的原因, 還是有方法知道結果, 而這結果更不須要只是靠 "模擬" 去檢驗, 因為網路上的 Log 早就記錄出最真實的數字, 可以計算出最真實的效率與效能, 因為他就是使用者在使用的真實, 而若這些數字都不可信的話, 你硬是要用你的 "模擬測驗" 來證明你就是很厲害, 我還真的不知道原來 "模擬" 可以 "凌駕真實" 阿.
因此我要在這邊讚揚虞發言人一下, 畢竟他已經是這陣子而言, 說話最接近真實的人了, 看過報告就知道這問題沒那麼單純, 只可惜他不是第一線的工程師, 應該也沒有這方面的實務經驗, 尤其他的本職是做商業決策, 投資政策的專家, 不是網路效率調校, 不然應該知道更多的細節在裏面, 能夠知道問題在那邊.
唯一他弄錯的就是拋棄 "實際資料" 而相信 "模擬運作資料", 認為國外一家公司的千億筆乘上千億筆真實使用者記錄是不夠好的, 而去更相信可能百萬次不到的測試結果, 認為 "台灣公正單位測試結果" 就推論說 "台灣網路表現比起國際並不差!".
所以我在這邊也更應該讚揚 "Akamai" 能夠定期公布這些資料, 去真實的了解各國的網路狀況, 這數字唯一的偏差就是這些資料會偏向國際性的服務, 而缺乏國內的流量, 因為 Akamai 的服務主要是像 Microsoft, Apple 這類的跨國企業, 區域性的廠商使用不多, 但這個倒是每個國家都一樣, 因此說是偏差很大也不盡然, 但就像我常說的: "任何資料都有偏差, 但你要知道如何使用他".
因此就這種資料分析的確可以知道問題點不是只有電信業者, 也不見得只有 ISP 業者, 這問題還很多, 只是這樣寫下去, 就寫不完了, 因此靜待下回分解... (若有下回的話)
[PS] 感謝林靖堂先生願意讓我使用虞先生的照片, 我覺得這張照得很好阿...
[PPS] 若想要更進一步了解 Akamai, 請洽併力科技.
訂閱:
張貼留言 (Atom)
熱門文章
-
在寫作 Google Friend Connect 的 Custom Gadget 時, 有發現有幾個重要的參數: 1. Site ID: 這個網站的 ID, 目前並沒寫在任何 Open Social 的 Spec 2. Personal ID: 判別誰是誰的東西, 最主要是拿來...
-
依 IMDB 超過 1 萬人以上評分的順序 降世神通 1. 9.3 Avatar 降世神通 2. 9.2 Ricky and Moorty 3. 9.1 鋼之鍊金術師 Brotherhood 4. 9.0 進擊的巨人 5. 9.0 獵人 6. 9.0 死亡筆記本 11. 8.8 ...
-
以下的言論, 純以我是以一個工程師出身的網管, 也以做過 ISP 基礎建設的工作經驗來發言. 前一陣子有人提出取消手機網路不應該有吃到飽 (Flat Rate) 的奇想時, 有參與網路發展的人都知道, 這個固定費率的使用量是網路發展的推手, 或者是指標, 甚至是門檻, 若把這...
-
一些比較消息靈通的人都知道 Seednet 做了一個 TaiwanRank, 以自己用戶的使用狀況來作網站的另一種排名, 而目前推出的指標是 DNS 查詢數 及 不重覆IP 的兩個排行.. 有人問我這樣到底準不準阿? 事實上我常說, 沒有一種指標或觀點能夠覆概所有事情, 當然是越...
-
雖然台灣的資訊科技網站或部落格真的很多, 但仔細看, 不少都是 "全文翻譯" 國外的網站, 不加任何自己的想法, 不然就是為了寫而寫, 此時來看, 不要說是獨立思考的創見已經看不到, 連獨立寫作的內容已經消失了. 這篇文章我早在去年 11 月時就想寫了, ...
-
一些無聊晃進來的朋友應該有發現, 左上角多了幾個之前沒看過的 gadget, 因為我又開始做無聊事了... 看到許多人裝 Google Friend Connect, 而我個人對較為開放的 Protocol 是採較為正面的態度, 所以就裝起來玩玩看, 覺得這是一個可以發展的東西,...
-
上一篇還有很多沒寫到的地方: 1. 在最初的規劃這個數字是 Increamental 的, 也就是為了避免沒有抓到資料時的問題, 而這三種數字有兩個是一直增加的, 一個卻是在變化的. 2. 在第二組的距離, 事實上最後應該只會採用一個, 做一下 x*y*z 應該對資源影響不大. ...
-
這篇報導是在 http://tw.news.yahoo.com/article/url/d/a/100809/11/2ar0a.html 這裏, 到中午, TWNIC 的人就一直打電話給我, 而我還在會議中搞不太清楚是甚麼, 但就大意上面指的都是講了很多有問題的話, 而我一上...
-
經營網站是相當不容易的, 尤其是維護一個知道無法賺錢的網站, 像這次 MyBlogLog 而言, 真的是發生很多很多事阿, 尤其對我而言更是要加上一筆. 1. 在部落格觀察之前, 有一個 Room 計劃, 是比部落格觀察更早規劃成熟的計劃, 是一個以到訪為觀點的足跡社群, 那值時...
-
在 SEO 圈的人, 看到我前一篇 " 從連結的生與死來談網站連結準則 " 知道是為了要回應嚴先生對於之前的連結做探討, 而前幾天有人說他也寫了 " 從 Nofollow 看 SEO 的未來 " 這篇來做回應, 我當下跟朋友說: ...
沒有留言:
張貼留言