見到CM已經有開始進步
真的很讚,畢竟良性競爭是好事情
恕小弟問一個問題
TP是什麼東西,用處在於?缺點是什麼?
ISP使用TP的壞處是什麼呢?
可列印頁面
見到CM已經有開始進步
真的很讚,畢竟良性競爭是好事情
恕小弟問一個問題
TP是什麼東西,用處在於?缺點是什麼?
ISP使用TP的壞處是什麼呢?
不影響一般上網遊戲等小量的網上用戶..倒是可以分享
因為長時間大量的下載用戶..有時真的會托慢速度耶!
我認為當然應該開放,實行若有問題在想辦法解決,總體來說應該利大於弊(對用戶來說)。
雖然小弟不是東森用戶 不過讓小弟說一點小弟的看法
綜觀台灣大部分的P2P用戶
用的P2P軟體幾乎離不開EMULE或是BT,KURO,WINMX等這幾樣P2P發布軟體
因為小弟發覺到P2P還要考慮發布的問題存在
如果不是很流行一點的P2P軟體 始終就是不是那麼多人用
相對的對網路效率傷害就比較輕一點
台灣這邊使用的P2P發布軟體始終都是那幾樣
小弟提出一個構想
如果說上邊可以偵測常用的應用程式中P2P軟體的封包的話
導入到另一個路徑在網內另做處理(上下頻寬另計 就不加入共享頻寬之內)
上邊網管可以視情形在尖峰跟離峰時段做用戶P2P頻寬的動態調整
技術面上就是不知是否可行否?
(小弟認為基本上一般互動式應用跟所謂的P2P應用上
基本上使用上就有點區隔)
我使用cable modem 玩p2p的感覺,
上傳頻寬是速率決定步驟..很容易就會拖慢下載速度.
上傳頻寬不夠,就算下載頻寬再怎麼大都是枉然的...
[QUOTE][i]最初由 testaho 發表[/i]
[B]小弟提出一個構想
如果說上邊可以偵測常用的應用程式中P2P軟體的封包的話
導入到另一個路徑在網內另做處理(上下頻寬另計 就不加入共享頻寬之內)[/B][/QUOTE]
或許也有很多網友和您一樣, 誤以為共享頻寬的瓶頸, 是在機房內; 其實不是.
共享頻寬指的是在用戶電路(Last mile, local loop)上的資源分享, 就像是 ADSL 的集縮, 雖然執行集縮的設備放在機房內, 但其實控管的是實體電路的集縮, 並不是機房內的集縮.
由於實體電路只有一條, 所以也沒有如您想像的「另一個路徑」可以走, 雖然我們可以在同一條電路內分割出不同應用的頻寬, 但不論 P2P 或其他應用, 都必須先一起走完實體電路, 才能進機房進行分流. 所以實體電路所能承載的總流量就會是一個瓶頸. 小弟先前提出的「QoS 管理」就是在試圖解決實體電路雍塞的問題. 「不限頻寬」概念則是要充分利用實體電路在離峰時間所剩餘的資源.
[QUOTE][i]最初由 raytracy 發表[/i]
[B]
由於實體電路只有一條, 所以也沒有如您想像的「另一個路徑」可以走, 雖然我們可以在同一條電路內分割出不同應用的頻寬, 但不論 P2P 或其他應用, 都必須先一起走完實體電路, 才能進機房進行分流. 所以實體電路所能承載的總流量就會是一個瓶頸. 小弟先前提出的「QoS 管理」就是在試圖解決實體電路雍塞的問題. 「不限頻寬」概念則是要充分利用實體電路在離峰時間所剩餘的資源. [/B][/QUOTE]
小弟的想法可能有問題 荒謬之處請見諒
小弟想要說的是從走完外面的實體電路進來後
是否有辦法可以企圖在同一條電路中分割出不同應用的頻寬出來
把p2P的這些零碎封包分開出來 做不同的處理 如此而已
「QoS 管理」「不限頻寬」達到充分利用離峰時段頻寬的概念
也是很好的想法
小弟也是期待您的想法有個好的結果出來..
[QUOTE][i]最初由 testaho 發表[/i]
[B]小弟想要說的是從走完外面的實體電路進來後
是否有辦法可以企圖在同一條電路中分割出不同應用的頻寬出來
把p2P的這些零碎封包分開出來 做不同的處理 如此而已[/B][/QUOTE]
會需要分開的緣由, 是因為遇到頻寬阻塞, 所以要讓互動應用先走; 不過, 在機房裡面, 甚至到連外頻寬以外, 在小弟這邊, 都沒有遇到頻寬阻塞, 因此不需要特別去分流.
就有點像是: 我在機房內有20線道的高速公路, 但卻只有 8 輛車要跑, 因此每輛車都可以自己占用一個車道全速前進, 不需要分流; 若此時還刻意去分流, 就好像硬把 8 輛車排在同一個車道內前進, 反而空了 19 個線道都浪費掉....
但實體電路的狀況則不同, 他是只有一個線道, 卻有 8 輛車想同時跑, 所以就要排個優先順序出來, 讓比較不重要的車晚一點跑, 重要的車可以優先超車.....
用戶第一個遇到壅塞的地方是 最後一哩電路, 其次是連外頻寬電路, 最後才是機房內骨幹電路. 不過, 在小弟這邊聯外頻寬和機房骨幹都很充裕, 所以只有最後一哩需要實施分流. 其他業者的狀況可能不盡相同, 他們實施分流的控制點也會不同.
[QUOTE][i]最初由 raytracy 發表[/i]
[B]但實體電路的狀況則不同, 他是只有一個線道, 卻有 8 輛車想同時跑, 所以就要排個優先順序出來, 讓比較不重要的車晚一點跑, 重要的車可以優先超車..... [/B][/QUOTE]
QoS可以設定優先權,
我比較好奇的是...
因上傳會影響到下載,所以P2P用互必須要自己對上傳/下載做限制,
才不致於影響到正常的網站瀏灠、收發Email。
甚至於抓檔案下載滿檔時,也一樣會影響到正常的網站瀏覽、收發Email。
如果使用了QoS,把P2P和下載檔案的傳輸優先權排在後面時,
會不會即使下載上傳滿載,也不會影響到正常的網站瀏灠、收發Email??
如果是這樣的話,就方便多了!
就不必瀏覽網頁、講網路電話時,還要調整抓檔/P2P軟體的上傳下載頻寬 :D:D
(不過...30M要下載滿檔也有點難...)
[QUOTE][i]最初由 Fabian C 發表[/i]
[B]如果使用了QoS,把P2P和下載檔案的傳輸優先權排在後面時,
會不會即使下載上傳滿載,也不會影響到正常的網站瀏灠、收發Email??[/B][/QUOTE]
如果 QoS 機制夠完整的話, 是可以做到這樣的. 不過必須兩端都做 (機房端, 客戶端), 如果只有一邊做, 效果有限....