我每次在上傳時一邊下載
好像下載的速度掉很多
本來20k
掉到5k
各位也有這種情形嗎

順變問一下
網路卡跟跟速度有關嗎

會使download變慢！

網卡的話、現在都是10/100M、應該都會取100M、
所以應該沒差！

[QUOTE]原始作者是 : [i] gpowdera [/i]
[B]我每次在上傳時一邊下載
好像下載的速度掉很多
本來20k
掉到5k
各位也有這種情形嗎

順變問一下
網路卡跟跟速度有關嗎 [/B][/QUOTE]

建議您看清楚什麼叫做"A"DSL
非同步模式傳輸下 本來上傳就會影響下載
要足的頻寬 請租用專線 or 用 雙向Cable

[QUOTE]原始作者是 : [i] sami [/i]
[B][QUOTE]原始作者是 : [i] gpowdera [/i]
[B]我每次在上傳時一邊下載
好像下載的速度掉很多
本來20k
掉到5k
各位也有這種情形嗎

順變問一下
網路卡跟跟速度有關嗎 [/B][/QUOTE]

建議您看清楚什麼叫做"A"DSL
非同步模式傳輸下 本來上傳就會影響下載
要足的頻寬 請租用專線 or 用 雙向Cable [/B][/QUOTE]

如果可以申請雙向cable的話
我早就申請了
專線......
別妄想了

沒錯...
一定會變慢...
像我們公司就是一個好例子...
只要一有人在寄檔案稍大的mail...
包準"ㄍㄧㄢ"(四聲)四起...
呵呵...這也是ADSL的缺點...

如果對於 TCP/IP 有所瞭解者皆知 , 這是當然的 !!

以下我就提出證明 :

假設我現在 Upload Data to [url]http://home.kimo.com.tw/xxxxxx[/url]

這時候 DU Meter 測得上傳速率為 AVG : 50 Kbit

然而 ADSL 512/64 的架構當中 , DSLAM 鎖住了線路頻寬

也就是你由 ATU-R 傳送出去的 DATA 流量需小於等於 64 Kbit

而考量到 TCP/IP 架構問題 , 一個框架當中, 有一個開始位元

與一個結束位元 , 如果以一串 8 bit 的 Data 而言 , 實際傳送

有效資料為 6 bit

所以 , 64 Kbit ---> 實體線路頻寬
51 Kbit ---> 經由 TCP/IP 的 傳輸層(Transport Layer)
的分割成封包(Packet)之後

由此得知 , 你可上傳最大極限為 51 Kbit

但是為什麼在上傳 Data to home.kiom.com.tw 時,此刻進行

瀏覽網頁(事實上就是在進行下載)會嚴重 Dealy 呢 ?

這是因為當你再下載資料(data)時 , 同時也會上傳資料

你可以做個實驗,將 DU Meter 開啟 , 然後再開啟 Broswer 瀏覽

此時你認為應當只有下傳資料啊!!為什麼 DU Meter 也出現了

上傳資料的長條圖形 , 這個原理很簡單 , 因為當你進行

Download Data 時 , 你的 PC 還是會傳送資料到 Server 端

例如: 下載速率為 400 Kbit 時 , 會上傳約 5.6 kbit

這就證明上傳時為什麼下載會嚴重 Dealy

因為你已將上傳的頻寬佔滿了, 導致下載時所需要的上傳資料的

頻寬無法使用或壅塞 , 因此會嚴重 Dealy ~~~

##########上述言論如有誤請糾正##########

原來如此啊
shyong兄
你真是學識淵博
請問你是用adsl
還是cable

嗯！
的確…
一般我們TCP/IP 網路通訊協定都是使用多交握式的方式來傳輸資料！(希望沒有用錯說法)
也就是如樓上的shyong版主所說的…
有下載就要有上傳…以來check資料！
相對的，上傳也需要下載check(其實就是一傳一送互相對調罷了)
可是偏偏ADSL的上傳又是超級的!@#$@$
所以當我們一上傳資料時，在下載方面所需要的上傳頻寬就被佔去…
導致下載遲遲無法獲得確認！此時資料就會low下來等待…
唉…
這是使用ADSL的悲哀…
真希望『真正寬頻』能快點來臨…

[QUOTE]原始作者是 : [i] JOHNNIE [/i]
[B]嗯！
的確…
一般我們TCP/IP 網路通訊協定都是使用多交握式的方式來傳輸資料！(希望沒有用錯說法)
也就是如樓上的shyong版主所說的…
有下載就要有上傳…以來check資料！
相對的，上傳也需要下載check(其實就是一傳一送互相對調罷了)
可是偏偏ADSL的上傳又是超級的!@#$@$
所以當我們一上傳資料時，在下載方面所需要的上傳頻寬就被佔去…
導致下載遲遲無法獲得確認！此時資料就會low下來等待…
唉…
這是使用ADSL的悲哀…
真希望『真正寬頻』能快點來臨…
[/B][/QUOTE]

======================

那麼 小弟有個 ideal 不知是否可行

1. Increase the sliding window size of TCP.
2. Decrease the sending buffer size.
So, it is supposed won't occupy too many resource.

請各位仁兄惠與指教

Thanks!

PS2178 所言的情形 ,正是我們長討論的 MTU 值

關於 Sliding Window 方面 , 修改之後似乎沒有什麼差別

至於減少送出的確認訊息

這方面屬於 ISO 中的 "資料鏈接層(Data Link Layer)"

有所規定 , 據瞭解是不能隨意改變的 ~~~~~~

因為這是為了確認所 Send Packer 到目的端的可靠性所制定的

也就是我們所謂的 Checksum

建議不要嚐試去修改這部分 , 否則可能會導致資料嚴重錯誤

如果考慮要加快速度的話 , 可以考慮採用 UDP Protocol

這可以少去 CheckSum 的 time