個人積分：73分
文章編號：18293980
個人積分：23分
文章編號：18294223
jim-lin wrote:
這幾天剛好再研究這個封包轉發率, 經過測試後, FTP or HTTP 這種下載的確是大封包再丟居多, 不過以現階段的網路應用層面來看, 尤其是P2P 軟體, 經測試90%都是小封包居多..
還有像是網路電話, IM即時通軟體, 與瀏覽網頁,網路遊戲..尤其是網路遊戲,都是小封包占多數,使用封包截取軟體後,可以看到封包大小:...(恕刪)
你的研究有問題，我相信IM或網路遊戲的封包應該是小封包為主，但是P2P的檔案下載不應該是小封包，因為我不認為編寫檔案傳輸程式的人，卻會選擇對檔案傳輸不利的小封包傳輸，這實在是一件很沒道理的事情，針對這一點我特地花時間去做了些實驗與考究，事實上反而證明P2P下載90%以上都是大封包....跟你說的是截然相反的資訊。
老實說，你附上的圖片有問題唷：
第一點，雖然你用Wireshark截了張圖，不過你點的欄位的Destination也就是目的地應該選192.168.1.100，這才會是「下載」的封包資訊，但是你點的欄位Source也就是來源卻是192.168.1.100，通常這是上傳。(一般來說IP分享器內部IP都是設定192.168.X.X，不會去設定10.X.X.X)
第二點，如果只截這麼一個上傳封包的圖，就說90%的P2P下載封包都是小封包？這樣未免太過分....
以下是我做的實驗，前二張圖是抓Hinet測試檔案時的節圖，總共抓20000個左右的封包進行統計：
第一張圖以目的地IP，也就是我的電腦192.168.1.100作為過濾條件，發現符合條件的有12825個封包。(因為這才是真正「下載」的封包)
第二張圖以目的地IP，也就是我的電腦192.168.1.100加上封包大於1024Byte作為過濾條件，發現符合條件的有12463個封包(所以這個條件就是「全部下載」的封包中大於1024BYTE的封包總數)
從以上二張圖可以發現，以HINET下載來說，大封包的比率大概有97%
幾乎都是大封包傳遞，這非常符合檔案傳輸的看法。
以下第3、4張圖，則是使用FOXY抓檔(只抓一個檔)來取封包，總共抓20000個左右的封包進行統計：
第三張圖以目的地IP，也就是我的電腦192.168.1.100作為過濾條件，發現符合條件的有11615個封包。(因為這才是真正「下載」的封包)
第四張圖以目的地IP，也就是我的電腦192.168.1.100加上封包大於1024Byte作為過濾條件，發現符合條件的有10599個封包。(所以這個條件就是「全部下載」的封包中大於1024BYTE的封包總數)
從第3、4張圖可以發現，用P2P程式FOXY下載檔案大封包比率是10599/11615，大概是91%
也就是P2P「下載」的封包90%以上還是由大封包組成，所以說P2P還是大封包轉發啊，怎麼會是小封包轉發？
就算把全部20000個封包都算下去，大封包還是過半啊....=.=
另外還有銘傳大學電腦與通訊工程學系的報告中指出，進行P2P檔案分享時封包大小的特性就是「大封包」超多與我作的實驗不謀而合。
連結如下：
www.mcu.edu.tw/department/itc/project/abstract/93/14.pdf
至於小封包轉發，實在沒測試的必要，除非是網咖要用的大ROUTER，或者大宿舍使用的產品，同時多人玩線上遊戲會用到，不然其實線上遊戲除非廠商很凱，不然小封包轉發數量一定不會太高，你想想看是對遊戲廠商來說是SERVER比較多，還是CLIENT比較多？
IM更不用說了，打ENTER打到手斷掉有辦法用到0.00XMbps嗎？
個人積分：44分
文章編號：18294269
個人積分：23分
文章編號：18294429
個人積分：73分
文章編號：18294643
個人積分：30分
文章編號：18303322
arcworld wrote:
至於小封包轉發，實在沒測試的必要，除非是網咖要用的大ROUTER，或者大宿舍使用的產品，同時多人玩線上遊戲會用到，不然其實線上遊戲除非廠商很凱，不然小封包轉發數量一定不會太高，你想想看是對遊戲廠商來說是SERVER比較多，還是CLIENT比較多？
...(恕刪)
1. Hinet 測速網頁就是文章前面實驗的結果產生->Http protocol...所以封包大多是以最大封包結構傳送!
整片綠色部分就是下載當中,的確都是http大封包
下載完成...
所以與您實驗結果是相同的! 這一點應該沒蛇摸問題,一開始就有說到http屬於大封包結構!
2. 改用Utorrent 的P2P下載...監聽port 設定為TCP 23261 ...
結果可以發現, P2P確實再傳輸當中,都是60多Byte 的小封包居多! 這裡應該修正一下, P2P的涵蓋範圍很廣,所以不同的軟體,有不同的表現方式!
TCP跟UDP都是網路封包傳送的方式,而網路在傳輸過程中,為了有效使用網路資源,避免過大封包沒傳完,而導致後方所有封包都不能傳送,故所有封包在傳送時都會被分割成小封包,然後在接收端重新組合,而採用TCP傳送封包,在接收端會檢查是否所有封包都完整接收到,如果有幾個封包在傳送過程中掉了,接收端會要求傳送端重送,故TCP方式傳送可確保封包完整,但唯一缺點是,相對於UCP,它傳送時間可能會比較久;反之,UDP在接收端沒有檢查機制,故用UDP傳送的小封包,有可能會不見而不被發現,一般TCP會被用在比較需要完整性的protocol如email,而UDP則用在只求速度,對完整性要求不高.
路由器性能規格項目中,所謂全雙工線速轉發能力最基本且最重要的功能是數據包轉發。在同樣埠速率下轉發小包是對路由器包轉發能力最大的考驗。全雙工線速轉發能力是指以最小包長（乙太網64Byte、POS 40Byte）和最小封包間隔（符合協議規定）在路由器埠上雙向傳輸同時不引起丟包(Packet Loss)。該指標是路由器性能重要指標。
Port輸送量是指埠包轉發能力，通常使用pps：包每秒來衡量，它是路由器在某埠上的包轉發能力。通常採用兩個相同速率介面測試。但是測試介面可能與介面位置及關系相關。怎能說小封包測試示沒意義的呢?
重點在路由器於大封包測試項目裡面表現很好,並不代表路由器的效能可以到多大, 而是真正看得出路由器的實際效能所在!
所以大大說到->除非是網咖要用的大ROUTER，或者大宿舍使用的產品，同時多人玩線上遊戲會用到...以這樣的規格效能來看, 若是連家用商品可以達到如此小封包轉發強悍的話,應該在Mobile01 上就不會這摸多苦水了!
經過此次爬文以及實際實驗後, 獲益良多! 或許這就是家用商品與企業/網咖/宿網等商品層級最大不同之處了..若是價格差異不是很大的話, 優選還是這些小封包效能突出的路由器為首選..
個人積分：44分
文章編號：18304789
===信件內文===
首先感謝客服的回覆
總而言之我就是必須等就對了
但這封回覆會不會有點不專業且很誇張呢??
第一封MAIL回覆說是IP分享器與VDSL搭配的問題
電話客服回覆我是IP分享器與VDSL韌體起衝突
現在回覆我是因為機器太舊不支援大頻寬網路???
若是NAT技術上的問題 但效能只有4M 這是2000年左右的技術吧??
而且早在2005年HINET就已經推出8M的ADSL
難道在2007~2008推出的產品會太舊而不支援4M以上頻寬??
自家東西無法互相搭配
難道這不是產品瑕疵是什麼??
卻用"舊產品無法支援最新的技術"來作為回覆客戶的故障理由
會不會太過於草率??
我只是想要知道一個解決方案
NBG-334SH在2008年的更新韌體後就已經沒有再更新過了
會因為我這個各案(?)而再推出新的韌體更新檔
機率會有多高我是不知道
但要全面更新VDSL韌體我想更是不可能
申請了20M網路 卻因為機器搭配的問題而無法使用到
諷刺的是VDSL也是貴公司的產品...
只想請貴公司能盡快給我一個解決方案
不要再拿一些似是而非的理由做搪塞了...
===信件內文===
不曉得他們會不會惱羞成怒...
個人積分：214分
文章編號：18305066
個人積分：44分
文章編號：18305497
個人積分：214分
文章編號：18308633
關閉廣告