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

 
(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 內建的 TCP/IP
      驅動器, 沒有「封包優先權」 的設計, 造成「上傳滿檔壓死下
      載」的奇特現象.
 
 
這張圖就是在說沒有收到「接收端」ACK 封包時, 「傳送端」停止
下一個封包輸出. 左邊是「接收端」, 右邊是「傳送端」. 紅色小方
塊是傳送端等待輸出的封包, , 正在傳送的綠色是「ACK 封包」, 由
於 TCP 交握機制的運作, 收到一個紅色小方塊時, 就必須傳一個綠色
小方塊對方, 告訴他我已經確實的收到了, 接下來才能再傳一個紅色
小方塊過來.
 
 
 
當上傳達到滿載的時候 , ACK封包便會被延遲送出 如上圖 , 如使用FTP
 Client軟體上傳較大檔案至遠端FTP Server 時 , 或使用P2P軟體上傳達到
滿載時 , 這個時候就會發現開啟網頁的速度 , 或連上BBS的速度很明顯
的變的緩慢 , 甚至完全連不上
 
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 來說,
這正是最迫切需要的功能.
 

 
 
arrow
arrow
    全站熱搜

    志 發表在 痞客邦 留言(0) 人氣()

    E-mail轉寄