【投票】下載30Mbps共享, 但是不保證頻寬?

[QUOTE][i]最初由 raytracy 發表[/i]
[B]用戶第一個遇到壅塞的地方是 最後一哩電路, 其次是連外頻寬電路, 最後才是機房內骨幹電路. 不過, 在小弟這邊聯外頻寬和機房骨幹都很充裕, 所以只有最後一哩需要實施分流. 其他業者的狀況可能不盡相同, 他們實施分流的控制點也會不同. [/B][/QUOTE]

小弟冒昧請問一下
最後一哩分流之後P2P方面如果再經過類似Proxy的專用伺服器
是否有可能改善P2P下載的機會
謝謝

[QUOTE][i]最初由 testaho 發表[/i]
[B]最後一哩分流之後P2P方面如果再經過類似Proxy的專用伺服器
是否有可能改善P2P下載的機會[/B][/QUOTE]
目前 P2P 沒有 Proxy, 不過有類似 Cache 的機制, 可以預先將外面的檔案儲存在近端的機房內, 避免連外頻寬或下載點本身的擁擠.

但是, 建置這樣的機制, 有幾件事情要考量.

1. 若 ISP 本身連外頻寬很大, 沒有擁擠問題, 則看不出有什麼必要, 去投資數百萬元, 來解決 P2P 的問題. 畢竟這樣的機制只有 P2P 用戶可以用, 但這些用戶並沒有額外為這樣的服務付費. 除非 ISP 自己的聯外頻寬被 P2P 塞得受不了, 才會考慮用這個機制來緩解. 不過, 要緩解 P2P 衝擊, 也不是只有這一個方法. 對 P2P 用戶流量設限, 可以更便宜, 更有效的解決壅塞問題, 只要業者願意承受 P2P 用戶流失的損失.

2. 這個機制建置之後, 假設聯外部份的壅塞被解決的話, 下一個雍塞點可能發生在最後一哩電路上. 這時業者又面臨另外一個抉擇: 是否要投資最後一哩設備, 去改善這個問題? 這段的投資, 就不是幾百萬可以解決的, 動輒數千萬, 經常需要上億元. 為了一群不能多收費用的 P2P 用戶做這樣的投資? 是否值得?

3. Cache 必須把資料存放在業者的機房, 如果 P2P 傳送的資料本身違反著作權法, 那業者是否要負連帶法律責任? 目前法界對此看法不一, 若業者的觀念比較保守, 不會貿然採取這樣的措施, 以避免公司不斷有官司纏身.

[b]Quality of Service (QoS) Q & A [/b]
[url]http://www.sysage.com.tw/Gst/NewTech/GNTOne.asp?PK=89[/url]

1.什麼是QoS
Quality of Service (QoS)乃是提供穩定、可預測的資料傳送服務，來滿足使用程式的需求。QoS並不能產生新的頻寬，而是依據應用程式的需求以及網路管理的設定來有效的管理網路頻寬。

2.以往的網路傳輸服務有何問題
IP(Internet Protocol)的資料傳送規格中，只針對傳送端及接收端的位址及服務等做出規範，並利用OSI第四層以上，如TCP等協定來確認資料封包的傳送無誤。但並沒有提供及保護傳輸的頻寬，而是以所謂盡力而為“Best Effort”的方式來提供頻寬服務。

這樣的方式對於以往如E-mail、FTP等服務倒還可以被接受。但面對ERP、電子商務、VoIP及VoD等多媒體資訊傳輸服務，則無法滿足這些應用的頻寬，以及低延遲的要求。

3.為何需要QoS
網際網路的資料流量隨著電子商務、多媒體資訊傳輸、大量檔案下載等應用呈現大幅的成長。瞬間大量的資料傳輸更影響了企業網路的使用效能。加大頻寬不但非常昂貴，並且不能保證能夠解決網路效能不足的問題。

4.QoS的好處
一般的Traffic Shaping，Queuing，Policy Management 或是Caching 的產品，或許能夠增加網路的效能，但卻不能保證重要網路應用的穩定運作及反應速度(Consistent response time)。QoS則能夠將既有的頻寬資源作最佳化的調整，相關機制的完整應用，對網路上的交通做到真正完全的控管。

5.QoS的頻寬/封包管理機制
QoS頻寬/封包管理機制，共有TCP Rate Shaping、Class-based Queuing、Fail Allocation of Bandwidth及Packet-size Optimization等四種，架構出最佳化的頻寬控管功能，能對網路上的交通做到真正完全的控管。根據使用者設定的策略做資料的分類，及時的將資料傳送出去，來滿足對於網路頻寬管理的精確需求。

6.重要的QoS參數有那些
重要的QoS參數包括Latency(延遲)、Jitter(不穩定性)、Throughput(頻寬效能)、Packet Loss(封包遺失)以及 Availability(高可用性)等。藉由這些參數便可以表現出QoS的效果如何。

7.與QoS相關的協定有那些
網路上有許多與QoS服務息息相關的通訊協定，藉由這些協定，能夠幫助網路相關設備對不同的封包提供不同等級的服務，這些協定包括：Int-Serv、DiffServ、MPLS、RSVP等。

8.選購QoS產品設備需注意什麼
如果QoS設備因任何原因而當機時，系統應該能夠自動變成如同一條網路線，雖然頻寬管理的功能喪失了，但不會影響總體網路的運作效能。此外，QoS設備的架設應能不需更改路由器、使用者電腦或是交換器的設定，以減少網路管理的負擔。

9.QoS產品設備還能有什麼附加功能
．Web Caching功能能夠有效的降低HTTP交通的高頻寬需求，以提供更多的頻寬資源給予”Mission-Critical”及”Latency-Sensitive”的應用，藉以在有限的頻寬中提供使用者最快的服務。
．簡易的設定/管理/監視系統，透過標準的瀏覽器(Browser)，管理者可以相當容易的設定相關策略，以及監控/了解即時的頻寬/服務使用狀況。

討論熱烈直得高興,過程也是讓小弟受益良多...
另外,
投票時限快到了...17x票是不是樣本空間稍為少了些? 需要在別的版面推廣嗎?

還好趕上囉
我贊成
總是要試試看吧
沒有嘗試怎麼知道這是可不可行的對不?
加油喔
期待您的產品

[QUOTE][i]最初由 stw_cbx 發表[/i]
[B]投票時限快到了...17x票是不是樣本空間稍為少了些? 需要在別的版面推廣嗎? [/B][/QUOTE]
小弟覺得, 這個過程對大家都有幫助. 樣本確實少了些, 不過說話要算話, 6/30 還是要先鎖一次, 讓小弟先整理一下, 後面二度開放時, 歡迎各位繼續向外推廣參予此主題....:D

現在時間是 7/1 0:06, 此票選暫告一段落!

小弟先關閉此主題, 進行資料彙整與統計, 各位如需發言, 請另開新主題. 待這一兩天小弟統計完畢, 發布結果之後, 會再重新開啟主題供大家討論.

這段期間, 非常謝謝眾多網友的參予, 以及 280 位網友投下您寶貴的一票, 小弟在此特別感謝!!

再次感謝各位的熱情參與, 小弟將各位的意見彙整在 [url]http://home.ubbn.net/ray/pczone2004junvote.pdf[/url] , 各位可以自行下載閱讀. 不過請自備 Adobe Acrobat Reader 軟體, 該軟體可由 [url]http://www.adobe.com[/url] 網站下載.

正式的投票作業在此告一段落, 接下來, 本主題繼續開放大家討論與投票, 但小弟不再進行正式的統計與意見彙整.

其實.. 最近深深發覺對外(國)頻寬比較重要,
同樣的速度的寬頻, 使用 hinet, 與東森 calbe,
東森就敗在對外頻寬, 這是讓我不想再續約的主要原因..

[QUOTE][i]最初由 lundi 發表[/i]
[B]其實.. 最近深深發覺對外(國)頻寬比較重要,
同樣的速度的寬頻, 使用 hinet, 與東森 calbe,
東森就敗在對外頻寬, 這是讓我不想再續約的主要原因.. [/B][/QUOTE]
而且東森cable使用視訊軟體，畫面慘不忍睹..........