傳輸的一個很怪異的現象,有人知道為什麼嗎 |
缺席
|
avex
初階會員 發表:19 回覆:49 積分:43 註冊:2003-03-28 發送簡訊給我 |
小弟分別用Indy及Borland 附的TCP socket 元件作傳輸實驗,
實驗的目的在求傳輸的封包大小跟反應時間是呈現何種關係: 傳輸架構如下,
實驗的數據結果如下:
無論何種封包size, 每一個封包均傳50次求平均, 所得的平均結果為"平均時間", 而 50 次內花最長時間的為 "最長時間". 反之為 "最短時間" 封包長度 平均時間 最長時間 最短時間 0 350 438 297 100 371.8 453 296 200 400 469 344 300 384.4 453 312 400 393.8 437 360 500 387.6 422 344 600 390 423 375 700 412.4 453 375 800 400 437 360 900 443.8 484 407 1000 393.8 438 359 1100 400 422 390 1200 400 438 375 1300 403.2 438 375 1400 403.4 438 344 1500 178 203 156 1600 187.6 203 172 1700 184.4 218 156 1800 184.2 219 156 1900 181.2 203 156 2000 193.8 203 172 2100 187.6 204 171 2200 200 218 187 2300 197 235 172 2400 200 218 187 2500 206.2 235 172 2600 206.2 234 172 2700 209.4 235 172 2800 206 219 172 2900 284.4 297 250 3000 290.6 312 266 3100 287.6 312 266 3200 297 328 281 3300 293.6 312 266 3400 300 313 281 3500 303.2 328 297 3600 303.2 328 281 3700 300 328 281 3800 306.2 344 266 3900 293.8 329 281 4000 309.4 328 281圖形如下: 實驗的結果是封包在大於1400 bytes 到 2800 bytes 之間反而要花費的傳輸時間較少, 有人知道為什麼嗎? 很奇怪, 1400 ~ 2800 剛好是介於 1個 MTU 及 2個 MTU 之間!! |
avex
初階會員 發表:19 回覆:49 積分:43 註冊:2003-03-28 發送簡訊給我 |
|
conundrum
尊榮會員 發表:893 回覆:1272 積分:643 註冊:2004-01-06 發送簡訊給我 |
先看看才知道為什麼
http://delphi.ktop.com.tw/topic.php?topic_id=31861
看了有為什麼
http://delphi.ktop.com.tw/quicksearch.exe/quicksearch?SearchStr=MTU http://www.wells.hk/ws_toolsdetail.php?tools_id=1103101899 Windows工具箱詳細資料
--------------------------------------------------------------------------------
主題: 更改MTU值去加速上網
主題內容:
MTU即為Maximum Transmission Unit,而每個單位為1 Byte,MTU是電腦在一段時間下,最高可以把資源傳送到網上的總容量。預設MTU值一般較少,為加大資料流量,可設定較大,但不要設定過大,否則出現Packet lost失掉資料的情況,反而拖慢速度。 先測試一下MTU值:在當接上寬頻後,在DOS模式下鍵入「ping -1 xxxx (MTU數值) www.xxxxxxx.com (網站)」去測試MTU值,然後出現:「Reply from xxx.xxx.xxx.xxx: bytes= “1462” time = 20ms TTL=251」,即表示資料傳送成功。MTU值可以由1462開始,然後加上去,重覆以上的測試,直至出現「Request Time Out」為止。例如MTU值測試到1500為最佳,但這值在接往不同的網址有不同結果,所以要多測試幾個不同網址以確定沒問題,然後以這值在RASPPPoE的設定值內加入。
【轉貼】Microsoft Windows 2000 TCP/IP ??詳細
http://delphi.ktop.com.tw/topic.php?TOPIC_ID=64978
|
avex
初階會員 發表:19 回覆:49 積分:43 註冊:2003-03-28 發送簡訊給我 |
首先, 很謝謝 conundrum 的回答, ^_^
我就是在做 MTU 的實驗才有這個結果的. 但是, 大家也看到了, 速度加快竟然是過了一個 MTU (1472 bytes) 才加快. 理論上, 當封包大於MTU時, 它是會被切成二個封包傳送, 所以傳送時間會增加才對, 但這個實驗卻得到不同的結果. 不論是用 Borland 的 TClientSocket/TServerSocket 或用 Indy 的TIdTCPClient/TIdTCPServer 結果曲線圖幾乎相同 程式非常的簡單, 應讓該不會出錯, 不知道大家寫的程式是否也有相同結果?
以 Indy 來說, 程式碼只是呼叫傳送/接收 stream 函式, 如下
[Client端] // 傳送的函式是呼叫
IdTCPClient->WriteStream(pStream, true, true, 0); [Server端] // 在 ServerExecute Event 中用相對應的 ReadStream 來讀取
AThread->Connection->ReadStream(pStream, -1, false); 我知道 802.3 10MHz 的網路會有 padding 的現象, 也就是不滿 64 bytes 會被填滿 64, 但應該與本題無關才對.
不知道是不是在 Router 或 hub 中是不是又有 priority 這種現象, 在這裡發問是想也許站上有人在開發網路卡之類的工程師, 可以解惑 先謝謝啦~~
|
conundrum
尊榮會員 發表:893 回覆:1272 積分:643 註冊:2004-01-06 發送簡訊給我 |
連不上一些網站的處理方法 MTU 修改
http://alfa.mtm.ks.edu.tw/computer/vbird_linux/linux_server/0140networkcommand.htm#MTU
http://www.microsoft.com/taiwan/msclub/member/TIPS/Spring_2001/tip1to3/tip1to3_2.htm 國立中山大學電機工程學系碩士論文
http://etd.lib.nsysu.edu.tw/ETD-db/ETD-search/getfile?URN=etd-0801103-195712&filename=etd-0801103-195712.pdf 此文寫的還真不錯喔
http://www.ns-bbs.com/teach/list.asp?id=87
如果封包沒有被切割﹐那麼 FO 的值為“0”。
http://www.ns-bbs.com/teach/list.asp?id=88 Indy及Borland 附的TCP socket 元件作傳輸實驗
如果說你也知道 你說的東西他底層與系統如何運作 才能談網路卡把
MTU 為什麼每一台都不一定 除了網路設備還有很多因素
就如網路卡是使用AUTO或100雙工等都會不一樣的
http://delphi.ktop.com.tw/topic.php?TOPIC_ID=75495
http://delphi.ktop.com.tw/topic.php?topic_id=71606
http://delphi.ktop.com.tw/topic.php?topic_id=50990
你可以使用比較純手工的vcl來了解如 ics套件
http://www.overbyte.be/frame_index.html
不然就真的手工打造啦 哈哈
引言:在這裡發問是想也許站上有人在開發網路卡之類的工程師, 可以解惑應該有把 不過只有等運氣了 也可以試試8866網友的tool玩玩 或思科資料把 |
avex
初階會員 發表:19 回覆:49 積分:43 註冊:2003-03-28 發送簡訊給我 |
儘管我問了智邦的工程師, 還是沒人知道. 但可以確定的一件事是, hub, router 只檢視 packet type.
不過, 若不是 hub 的問題, 應該存在程式上有什麼東西在搞鬼. 最後, 我找到問題所在了,在 win socket 傳輸裡面存在著一種叫 "擁塞控制演算法" 的東西, 它不是縮小傳輸的視窗,就是限制小的資料元。normally 是 enable. disable 它就可以了. 雖然 conundrum 沒有講到正確的問題所在, 但我還是很感謝他的幫忙, 所以 分數當然還是給他囉, 謝啦~~
|
conundrum
尊榮會員 發表:893 回覆:1272 積分:643 註冊:2004-01-06 發送簡訊給我 |
avex 你好
1 感恩感恩 2 請問一下你有去測試我po的網站嗎? 題外話
1 進入 http://www.speedguide.net/
2 點選TCP/IP Analyzer 產生數據 庵的 MTU = 1492
MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput.
MSS = 1452
MSS is optimized for PPPoE DSL broadband. If not, consider raising MTU to 1500 for maximum throughput.
Default Receive Window (RWIN) = 373160
RWIN Scaling (RFC1323) = 3 bits (scale factor of 6)
Unscaled Receive Window = 46645 For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
511104 (MSS x 44 * scale factor of 8)
255552 (MSS x 44 * scale factor of 4)
127776 (MSS x 44 * scale factor of 2)
63888 (MSS x 44)
bandwidth * delay product (Note this is not a speed test): Your RcvWindow limits you to: 14926.4 kbps (1865.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5970.56 kbps (746.32 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 23 hops TTL value is ok.
Timestamps (RFC1323) =
Timestamps (RFC1323) = ON
Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000 (0)
|
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |