如果真的，那以後就不用擔心上傳會影響下載了，那p2p分享才有可能更好 http://twed2k.no-ip.org/discuz/viewthread.php?tid=90493&fpage=1 cFos Speed，只是單純的線路優化軟體！ cFos 則是包含線路優化及撥接功能的軟體，在位階上及功能的多樣化上是高過於 cFos Speed 的。 兩者無法共存，也沒必要！因為會有互搶 COM Port 的情況！ 如果使用的是撥接式的 ADSL，我會建議使用 cFos，利用它的撥接功能來取代原系統內建的撥接程式。 固撥的話，那就選擇 cFos Speed，作線路優化即可。 這是我使用過效能優化程度最為顯著的軟體，強烈建議大家試試！ 尤其是在 P2P 下載及上槫檔案的同時，網頁瀏覽，頁面刷新的速度會有相當大程度的改善。 若再能搭配 FireFox 的瀏覽器的話，那麼可以感受到的速度改善真令人訝異。 [Rev 2, 2005-8-10] 忘了告訴各位使用 cFos/cFosSpeed 的網友 原文 (cFos 的 Help 中, 並非本文), 有提到「校正 cFos 線路適應性」的文章 連結在此 http://www.cfos.de/traffic_shaping/explain_e.htm?calibrate 最後面是重點, 因為看到有些網友說速度反而更慢 才發覺可能是這個步驟沒有執行造成的 (或許吧….因為我也遇過這樣的狀況) 校正 cFos/cFosSpeed 的步驟 (為何要校正? 因為 ADSL 的傳輸比每個國家地區都不同, 所以 cFos 必須要知道這條線的最大上傳與最大下載分別是多少) (1) 待測 ADSL 網路淨空, 也就是沒有任何電腦使用到頻寬 (2) 確定打開 Traffic Shaping 功能. (3) cFos/cFosSpeed 執行「clear calibration data」(我灌的是日文版, 英文應該是這樣的字, 中文應該是清除校正資料等意思) (4) 純粹全速下載!! 最好的方法就是找個大檔案下載 (千萬別用 P2P, 因為會動到大量上傳), 這樣的過程建議超過 10 秒. 然後停止下載. (5) 純粹全速上傳!! 最好方式, 就是發一封 eMail, 夾個大檔案 (建議超過 5MB) 給自己, 但也不用真的把這封信傳完, 只要能保持全速上傳約 60 秒就可以了. [6] 經過 (4) and (5) 以後, cFos/cFosSpeed 就會紀錄那條 ADSL 的特性參數, 詳細參數可用 cFos 控制台, 然後鍵入 cfo speed (cFos) or spd speed (cFosSpeed) 指令看到, 參數大概有幾十種吧, 不僅僅只是單純的上傳與下載參數而已. 所以校正的工作很重要.

(7) 筆者另外發現一種懶人校正法, 步驟同 (1), (2), (3), 然後選擇「發送校準信號脈衝」, 他也會做同樣的校準動作, 至於成效嘛……我覺得有待改進, 可能是校準的持續時間太短, 大約只有 10 秒鐘而已. [最初的原文在此] cFos v6.00+ 與 cFosSpeed v2.00+ 提供一種新的上傳流量「封包重新排序」的功能，稱之為「Traffic Shaping」.

那什麼是 Traffic Shaping? 原文在此 http://www.cfos.de/traffic_shaping/traffic_shaping_e.htm

筆者用了幾週以後, 覺得確實需要推薦給常用 P2P 的網友 就 TCP 封包交換的過程, 先說明一下.

(1) TCP 採取交握式封包傳送機制, 傳送端必須等待接收端的 ACK (認知) 封包傳回後, 才會繼續傳送下一個封包. 也就是說如果, 傳送端一直等不到接收端的 ACK 封包時, (1a) 他會一直等待到傳回 ACK 為止, 這段時間他不會傳送任何新的封包 (1b) 超過時間後, 他會切斷與接收端的通信.

(2) 為此, 現有 ADSL 多半建議使用者將 TCP 封包長度僅可能開到最大, 目的是減少 ACK 交握訊號的次數. 然而這麼做會有個副作用, 就是在全速上傳時, 排隊在後面的 ACK 封包, 會因為前一個封包上傳佔據大量時間, 無法「及時」傳送給「傳送端」, 造成 (1a) or (1b) 的狀況.

(3) 如果將 TCP 封包長度減少, 則單位時間內 ACK 交握次數增加, 「或許」可以減輕因為全速上傳造成的排隊中, ACK 封包的延遲「機率」, 但仍然因為較多的 Overhead (封包本身的控制區塊所佔用的頻寬), 也沒有佔多少便宜.

(4) 整理 (2) and (3) 可發現, 問題都出在 ACK 交握的時間點是否能在「傳送端」等待時間之內, 這是因為 Windows 內建的 TCPIP 驅動器, 沒有「封包優先權」的設計, 造成「上傳滿檔壓死下載」的奇特現象. 這張圖就是在說沒有收到「接收端」ACK 封包時, 「傳送端」停止下一個封包輸出. 左邊是「接收端」, 右邊是「傳送端」. 紅色小方塊是傳送端等待輸出的封包, , 正在傳送的綠色是「ACK 封包」, 由於 TCP 交握機制的運作, 收到一個紅色小方塊時, 就必須傳一個綠色小方塊對方, 告訴他我已經確實的收到了, 接下來才能再傳一個紅色小方塊過來.

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x 那麼啟動 Traffic Shaping 以後的結果是什麼? 圖 很明顯的發現, 綠色的小方塊 (ACK 封包) 可以「插隊」在藍色小方塊之間, 而且插隊的位置, 是在下一個要傳送封包的預備位置, 也就是說, 封包之間產生了「優先權」的機制. 所以紅色小方塊 (下載) 可以不受藍色小方塊 (上傳) 的影響, 繼續的輸出資料給接收端. 對於 P2P 來說, 這正是最迫切需要的功能.

如此一來, 即便上傳達到滿檔, 依然可以保持不斷的下載, 也就是說「上傳與下載之間的關係, 不再互相牽制, 上傳滿檔壓死下載是歷史名詞」; 至少筆者試用幾週來, 約有 95% 的時間, 看到上傳與下載各自滿檔的狀況, 在過去這是不可能的, 只要上傳達到滿檔, 接下來下載就準備陣亡, 現在有了 Traffic Shaping 這種機制, 此情形已經看不見了.

cFosSpeed 官方下載點: (目前沒有適合的註冊機) http://www.cfos.de/cfosspeed-v210.exe

cFos 官方下載點: (註冊機參考附件) http://www.cfos.de/cfos-nt-2000-xp-v610.exe

如果你用的是 Win95/98/Me, 請在官方下載安裝程式, 註冊機可能包含在下面這個 eD2k 之中, 我沒下載過. http://www.cfos.de/cfos-win9x-me-v610.exe CFos.v6.10.Win9xME.Incl.Keygen-ECLiPSE.zip 附件使用方式: 輸入三個項目以後, 會自動產生一個 CFOS.KEY 檔案, 接著打開 cFos 的「窗口」, 按住這個檔案, 拖動到 cFos 的「窗口」上 (會出現加號), 自動完成註冊. 你也可以將 CFOS.KEY 檔案直接複製到 cFos 安裝路徑中, 重新開機也能註冊成�. http://twed2k.no-ip.org/discuz/attachment.php?aid=13590&checkid=9b949&download=1