| 會員  | 凱妹就別插花了, 你那100M/100M 光纖又不用像大夥兒這樣辛苦討論, 不夠用? 再申請一條不就結了! 基本上, 小弟覺得大家沒把自己的前提假設說清楚, 所以才形成雞同鴨講, 請62chaokai 兄勿介意成為小弟舉例的目標, 純粹只是討論技術上的問題, 因為有現成範例比較實際, 否則還是各說各話, 小弟認為你的管理方式就已經可以做到 "下載最大2Mbps, 遊戲不會累, 上網也順暢", 請不用謙虛, 但是請問如果將貴大樓那一套系統移植到樓主的宿網環境, 需要採行多大的變動? 初期的流量觀察和調整那是一定的, 請問你建議樓主採用哪一套OS? 哪些硬體? WAN 頻寬多少? 既然你也認識不少位於屏東高雄的宿網房東, 是否可以具體比較一下軟硬體設備和房客數? 小弟倒是覺得linux_xp 兄在#78 提到了一些很現實的問題, 那些情形可能不常發生於公寓大樓的管委會網路, 小弟也並非刻意將學生房客抹黑成洪水猛獸, 相信對於宿網所可能遇到的問題, RouterOS 兄和youngboris 兄也一定很有經驗, 忘了是在哪兒看到, 宿網用戶為了惡整網管, 故意於上課前開啟ICS (DHCP), 讓網管找不到人, 當然這種情形不會經常發生, 如果一開始就妥善規劃, 問題也許就不容易發生 話說回來, 樓主可能已經拿定主意, 所以是否能討論出個結果也已經不太重要 |
| 回覆 |
| www.ublink.org  | 回覆: 請教關於新建宿舍網路規劃 FYI兄說的好 一開始先規劃好 其他的問題都只剩管理面的問題了 !! ivantw兄不知道有沒有在德國被抄包 ^^ http://udn.com/NEWS/FINANCE/FINS4/4248780.shtml |
| 回覆 |
| 會員 | 千金難買早知道 引用:
| |
| 回覆 |
| 會員  | 回覆: 請教關於新建宿舍網路規劃 圖片疊疊樂好有趣哦!  哇 雙下100M:  可以包個各學校了.時間管制使用p2p軟體,是一套非常好的管理辦法,戶數可以再增加,而線路不需再增加,非常值得參考.  在一棟有300戶社區有120戶上網,每戶各有2M最大頻寬,源頭1線光纖10M/2M,當其中有人用foxy時該人可實際下載到2M頻寬,同時其他用戶玩遊戲不會lag,其他用戶上網瀏覽網頁也很順暢不塞車. 普遍在台灣推出頻寬規劃有很多的方案如: 1M/64K,2M/64K,3M/64K,2M/128K,2M/256K,3-8M/128K,3-6M/256K... 那個規劃對現實環境最重要,還要斤斤計較的有限頻寬內,選對規範成功失敗就在其中,或許上傳64K就很夠用了,遊戲 SKYPE都還不錯,但能夠再高一級時可避免突發狀況. 台灣芒果兄上網的頻寬規格真的是值得參考的規劃.  此篇文章於 2008-03-08 01:24 PM 被 needmaster 編輯。. |
| 回覆 |
| Kree | 回覆: 請教關於新建宿舍網路規劃 我來說說實際一點的東西 基於省錢的原則，硬體路由器就先不考慮了，交換器暫定用普通的 最佳選擇，當然就是大家都熟悉的老朋友「軟體路由器」了 先說明這是一般玩家 DIY 的可行作法，和專業的比可能會像是小孩子辦家家酒，僅是個人看法。目的不在於提供專業的網路，只是用最低的成本，做簡單的網路分享。看不下去的大大，也請手下留情。 需求有： ----------------------- 1.NAT 2.QoS 3.Firewall (防火牆對外、對內雙向) 4.Transparent Porxy （非常重要，一定要有） 5.DNS Cache 6.PPPoE server 具體構想： ---------------------------- 1.用戶用 windows 內建的 PPPoE 撥接，取得 IP 或網段，才能上網，每個用戶帳號不一樣，取得的網段已事先在 server端規劃設定好。因不是採用 DHCP，區網內有人要惡搞 DHCP 也沒用。另因各用戶網段都不一樣，形成有子網切割的效果，可防止用戶間網路互通，造成病毒或惡意攻擊等問題。 2.下載都強制 Transparent Porxy，用戶端不必設定任何東西，是路由器端強制路由的，也就是說用戶不會感覺到他們是透過 proxy 上網的，將快取物件上限值加大到 64MB 或 128MB，這台 proxy 要有很大的磁碟陣列。 具體就是有人下載過的網頁，在時效內會存於 proxy 快取中，下次再有人下載該網頁，直接取用 proxy 快取資料，不必在連外去下載，幾乎大部分人都會將 yahoo奇摩 設為首頁，可見這可以節省多少頻寬，因快取物件大，yutobe 之類的 flash 網站，熱門的 flash 影片也都能快取住，假設有一個人去下 64MB flash 影片檔，被 proxy 快取住，其他人再去下載，直接取用快取資料，即省下 64MB，相當可觀。更別提 P、Y 購物網站，無名...等等的大量圖片網頁，只要能快取到，省下的頻寬都是巨量的。 3.用 QoS 機制，限制每個用戶 (PPPoE 配給網段）的可用頻寬，假設是 10M/2M，120 戶 上傳方面因為太小， 2M （256KB/s），直接分割，每戶都保證 2kb，最小、最大都是 2kb，避免搶頻寬，影響遊戲，用掉 240kb，剩下 16 kb 給路由器伺服器使用 (proxy、dns等)。 這邊可能會有認為用戶實際上線不是 100%，是否可設最小保證 2k，最大放寬到 4kb，個人的心得是最好不要這樣做，因為保證頻寬是不管用不用的到，都要保證維持的，若最大放寬到 4kb，多的要從哪裡來？就不合數學邏輯，實際會發生搶頻寬的情況，雖會被 QoS 抑制下來，但 QoS 本身也是處理程序需運算時間，哪怕只是幾毫秒，都會導致遊戲短暫 LAG 爆 ping，具體就是遊戲打的正爽，結果 ping to high 被 server 踢出來，要在連已經客滿，或者PK的正爽，一個 lag 就被打趴在地板上了。 下載方面夠大，10M (1280KB/s)，先保留 4M（512KB) 給 porxy 用，別人都不能和它搶，因為 porxy 負責網頁最重要，什麼 LAG 都還可以忍耐，唯獨網頁不能看肯定有人跳腳。每戶最小保證 4kb，以維持 msn、skype 等聊天軟體可以穩定運作，扣一扣看還剩下多少，加上去就是最大上限（大概還剩 312KB 左右），這多出來的數值一樣可以加到 proxy 的最大上限值。 當然這邊是假設 10M/2M 真能跑到 10M/2M，即使不能，還是無所謂，照樣這樣割，只是達不到上限值而已，還是可以保障最低頻寬。 10M/2M 要供 120戶，其實有點勉強，能用雙 WAN 多個一條會比較好。以每戶保證最小 2KB 來講，其實打遊戲還是不太夠的，但以廉價/免費網路來說，以不期滿足所有人，只要滿足大部分人即可的觀點來看，把網頁應用列入最優先就對了。 路由器 OS 選擇： ------------------------- 現成的軟體路由，或多或少都有功能不足的地方 以 BrazilFW 來說，雖具有良好的 NAT/QoS 性能，內建方便的 L7 管制，也可寫 iptables 規則，但畢竟是嵌入式系統 shell script 程式寫作方面比較薄弱，指令搞要程式化有困難，在加上無法安裝 porxy，必需要用導向的方式導到另一台 porxy 伺服器，變成要兩台，所以不適合。 IPCOP 有 proxy，不過感覺性能沒有 BrazilFW 來的強，具體 L7 那些都要額外安裝，iptables 指令的附加也比較麻煩。 其餘軟體路由沒用過，不方便發表意見，但估計或多或少都有不足的地方。最主要若 PPPoE server 搞不出來，都不必考慮了。 所以最佳選擇當然非 Linux 莫屬啦 (unix-like) FreeBSD/OpenBSD BSD 系列的也可考慮，看人啦，個人是覺得 Linux 在這方面應用，資料較好找 NAT、Transparent Porxy、DNS Cache 這些就不用說了，鳥哥網站都有教學，市面上很多書籍也可買來看。 QoS 部份就比較麻煩了，要寫 shell script 指令搞，不過主要 QoS 是 iptables 和 tc 指令做出來的，重點還是在 iptables 和 tc，shell script 寫不寫都無所謂，寫了是有自動化的好處，以後要改只需改數據，不寫指令搞要一行一行湊出來也是可以跑。這部份的知識，買書來看，學習是會比較快的。 Linux PPPoE server 搜尋一下還蠻多資料的，以前總納悶平常人搞這玩意做什麼，經前面網友大大提醒，恍然大悟，原來是要用在這種用途的。 至於 L7 封鎖 P2P，就乾脆放棄了，其一、是用戶端藉由 PPPoE 取得專屬網段，QoS 方面能有效限制它的可用頻寬，用戶想怎麼用就怎麼用，P2P 啥的一起來都沒關係，反正他的可用頻寬就是只有這樣子，他要怎麼用都是他家的事情，不會影響到其他人。其二、標準 Linux distro 是沒內建 L7-filter 的，要重編核心，難搞是一回事，重編核心後就不能自動升級了，徒增安全性維護方面的困擾，試過好像也不太理想，會擋到不想檔的。其三、現在 P2P 不是加密、就是冒出一堆新型的，L7 過濾器定義檔根本抓不到，裝心酸的。綜合這幾點，判斷為乾脆不裝比較省事。 .....暫時就想到這些 PPPoE server 的東西沒實做過，純理論 其餘 QoS、NAT、Transparent Porxy、DNS Cache 用過，效果很不錯，家裏分享網路也是用這一套 歡迎有興趣的網友繼續補充、討論 |
| 回覆 |
| 我是嫩咖 | 回覆: 請教關於新建宿舍網路規劃 引用:
比如上傳是多少？ 用foxy實際可下載到2M，那是指「幾人」？不會只「允許」一人吧！ ： 我想不只是第七代，就算是第八代、第九代……到第一百代的「寬頻管理器」都只能「管理頻寬」而不能「放大或增加頻寬」！ 不好意思，也許有點冒犯，還請見諒。 | |
| 回覆 |
| 會員  | 回覆: 請教關於新建宿舍網路規劃 引用:
所以我之前才會回"10M/2M...120人用" 不要說下傳10M分給120人用............. 上傳2M分給120人用才是大問題........  | |
| 回覆 |
| 會員 | 阿斌兄和凱妹不用太執著, 有些技術也許是營業秘密, 也許必需長篇大論, 只要needmaster 兄仍持續補充置頂的頻寬管理專文, 相信早晚看得到結果, 而小弟注意到該篇#187 所提到的幾個重點, 都可以在小峰兄的明誠頻寬管理版看到, 所以小弟才會單純得認為, 可以在樓主的各樓層配置一台明誠頻寬管理版, 或者兩層樓配置一台Vigor2910 做Dual WAN 負載平衡, 算一算也許每月的變動成本由一條WAN 提高到四條WAN, 但是除了滿意度提高之外, 整體費用則大大減輕, 如果以樓主目前所洽談的每月1.6 萬方案, 兩年下來合計38.4 萬, 假設每月連線費也是以WANx4, NTD4000 計算, 那麼硬體加上管理費用合計28.8 萬, 相信眾位高手應該可以做的更多吧! 小弟相信把多出來的錢, 用來購買硬體和聘請62chaokai 兄當顧問, 實在綽綽有餘, 以上計算是以兩年為基礎, 如果五年更換設備一次, 那麼所節省的費用更為可觀 以下可以請小峰兄補充, 明誠頻寬管理版的效能約18Mbps, 因此絕對可以勝任10M/2M, 雖然小峰兄評估適合於30 台電腦以內的環境, 然而小弟認為如此等級的CPU (200MHz MIPS32), 影響效能的關鍵在於連線數, 如果控制好連線數, 那麼同樣可以應用於120 台的環境, 假設30 台合用6000 個連線數 (上限10240), 平均每台200, 如果分配給120 台, 那麼每台就是50 個連線數, 基本上這個數值和EventID4226 的作者所建議的數值相同, 所以唯一會受影響的應該是P2P 的應用, 如果房東決定一條10M/2M 的費用(NTD1000)自行吸收, 那麼只要一台明誠頻寬管理版就夠用了, 主要花費不如用於能有效管理頻寬的二層交換器之上, 以交換器控制每埠的最大頻寬和保證頻寬, 這讓小弟想起當初討論BM-26 時, 門神兄曾建議另加一台分享器管理NAT, BM-26 管理頻寬, 這樣可以有效減輕BM-26 的負荷, 如此建制應該也可以應用於一般獨棟公寓大樓的管委會網路, 原則上, 10M/2M 提供基本上網服務並不為過, 小弟另外的構想是將用戶區分成兩組, 如果頻寬提升到20M/20M 或50M/3M, 那麼就可以接受部份用戶付費提昇最大頻寬和連線數, 例如免費住戶最大頻寬為1M/64K, 保證頻寬為32K/2K, 50 個連線數, 部份住戶如果不能滿足於現況, 卻又不想獨自申請ADSL, 那麼只要支付少許費用, 就可以將最大頻寬提昇為3M/64K, 保證頻寬64K/4K, 100 個連線數或更高, 只要網路使用率並非100%, 那麼達到上限的機會是很高的, 使得頻寬可以更有效利用, 這也是共享頻寬的目的, 以上不知62chaokai 兄可曾考慮過? 可行性如何? 是否會增加管理者的負擔? 此篇文章於 2008-03-09 02:04 PM 被 FYI 編輯。. |
| 回覆 |
| 我是嫩咖 | 回覆: 請教關於新建宿舍網路規劃 引用:
我想這是重點！10m/2m提供給「120人」基本上網服務，例如看看網頁、收收信，不為過！ 但是還可以用P2P，而且「保證」實際可下載2M！我想這就偏「誇大不實」了一點！ 之前needmaster兄在版上發表高見，小弟也是學了不少。但這並不代表他就可以發表錯誤的觀念和「疑似誇大不實」的「廣告」，也不代表才疏學淺的小弟就不能提出「合理」的質疑！ 不然大家都以這種「隱藏但書」的方式來打廣告，那跟「陰森購物」或是「黃色鬼屋」又有何不同！ | |
| 回覆 |
| www.ublink.org | 回覆: 請教關於新建宿舍網路規劃 或許我們都忘了啥米是"TDM"技術 ! ^^不是TMD喔 !! needmaster有說到是硬體效能問題 !! 或許樓主如果還有興趣 可以直接敲needmaster問問看 此篇文章於 2008-03-09 04:58 PM 被 門神 編輯。. 原因: 補上樓主或許可以問一下needmaster |
| 回覆 |
| XML | RSS 2.0 | RSS |
本論壇所有文章僅代表留言者個人意見，並不代表本站之立場，討論區以「即時留言」方式運作，故無法完全監察所有即時留言，若您發現文章可能有異議，請 email :[email protected] 處理。
