現(xiàn)實網(wǎng)絡(luò)世界 多少帶寬才會夠用

申請免費試用、咨詢電話：400-8352-114

“帶寬”對于網(wǎng)絡(luò)管理人員、建筑師和技術(shù)人員來說是毫無意義的一個術(shù)語，相反，他們使用“數(shù)據(jù)傳輸率”、“連接性能”或者甚至“網(wǎng)速”來簡單地代替這個術(shù)語，這就說明了一個問題，我們對網(wǎng)絡(luò)有點無知，至少對在OSI模式的7個層次中的第1層是比較無知的。許多人可能使用“帶寬”來表示比特每秒，但是這樣做就反映了對信號理論和基本物理通信的無知。下面所回顧的術(shù)語顯示了即使是它們的物理特性也是不一樣的。

帶寬：以赫茲（Hz）作為測量單位——一個信號或一個傳輸信號的頻道的頻譜寬（以往表示為：周期每秒）。

數(shù)據(jù)傳輸率：以比特每秒為測量單位（或者可能是兆每兩周）。

“帶寬”往往被草率地應(yīng)用于錯誤的上下文中，或者被用于一些看起來挺怪異的場景中。這是相當(dāng)糟糕的，因為網(wǎng)絡(luò)新手們很容易被誤導(dǎo)而非受到正確教育。這里有一個適當(dāng)?shù)慕忉?。在Claude Shannon工作中：“帶寬”就如同農(nóng)田。對這塊農(nóng)田的開墾方式將收獲一個特定的數(shù)據(jù)傳輸率。

許多前輩，如Dennis Hayes，花費了大量的精力，致力于通過調(diào)制解調(diào)器實現(xiàn)Shannon的假定的權(quán)限（香農(nóng)極限）來將未經(jīng)處理的帶寬轉(zhuǎn)換為位/秒。他們使用了靈活、明智的信號符號（FSK、SQPSK…）選擇——這樣就能從任意指定的頻道帶寬中獲取非常好的數(shù)據(jù)傳輸率。

一些歐洲國家已經(jīng)定義的編碼與香農(nóng)極限（Shannon Limit）非常接近。但是，并沒有任何情況顯示帶寬與數(shù)據(jù)傳輸率是一樣的。相反，它是通過一個精心挑選的傳輸符號來要求智能開發(fā)的機會——甚至Napoleon網(wǎng)絡(luò)的設(shè)計者早在200年前就知道了這個方法：他建立一個跨越歐洲的光纖網(wǎng)絡(luò)以實現(xiàn)在15分鐘之內(nèi)能將國王命令發(fā)回巴黎的通信時，這是使用一個20位符號的代碼實現(xiàn)的。瑞典人也在200年前擁有了他們自己的521位符號光纖網(wǎng)絡(luò)。而當(dāng)計劃與Voyagers通話時，NASA肯定是知道這個的。

那么在網(wǎng)絡(luò)節(jié)點Y和Z之間到底需要多少“X”每秒的速度呢？這要依據(jù)具體情況而定的。

網(wǎng)絡(luò)管理人員、工程師或技術(shù)人員最為關(guān)注的可能是他們從老板、主管部門、商業(yè)伙伴以及最后從用戶那聽到的投訴。每個網(wǎng)絡(luò)管理人員都知道“一對一的抱怨”的呼叫：“速度太慢了！我無法連接到服務(wù)器ABC!系統(tǒng)Q把我踢掉了！打印機也很慢！今天的網(wǎng)絡(luò)真是慢！”

哪些問題與網(wǎng)絡(luò)建筑師、管理人員或技術(shù)人員能夠改正的參數(shù)有關(guān)呢？這些都是跟實際情況相關(guān)的，能讓系統(tǒng)和用戶完成工作的是吞吐量，也就是按順序從發(fā)送者到接收者發(fā)送的良好的數(shù)據(jù)位/字節(jié)的完整數(shù)量。

多少吞吐量才夠呢？

那么，我們真正關(guān)心的問題是：多少吞吐量才夠的呢？在OSI模式的每一層，吞吐量問題都是應(yīng)用設(shè)計師必須指定、架構(gòu)師必須設(shè)置、管理人員必須維護，以及技術(shù)人員必須測量和修復(fù)的。事實上這也是系統(tǒng)和用戶每時每刻都在經(jīng)歷的事情。

延遲和連接是兩個關(guān)鍵的可測量網(wǎng)絡(luò)屬性，它們對吞吐量的影響正是服務(wù)的系統(tǒng)或用戶所體驗的。延遲表示請求的響應(yīng)所耗費的時間長度，而連接則可以簡單地認(rèn)為是一個節(jié)點到另一個的可見性。這些都直接地影響著網(wǎng)絡(luò)的“性能”，而且現(xiàn)實情況是，物理性網(wǎng)絡(luò)并非總是造成網(wǎng)絡(luò)性能低下的根源。問題根源可能是一個不正確建造的數(shù)據(jù)庫或一個配置不當(dāng)?shù)姆?wù)器、應(yīng)用、路由器或防火墻。甚至還可能是節(jié)點、客戶端或服務(wù)器中的配置不當(dāng)?shù)臄?shù)據(jù)傳輸協(xié)議。這里只是概括了網(wǎng)絡(luò)故障修復(fù)的難題，而這些問題在目前復(fù)雜的互聯(lián)系統(tǒng)和應(yīng)用中變得更加嚴(yán)重。

如果網(wǎng)絡(luò)架構(gòu)得當(dāng)，那么技術(shù)人員對諸如鏈接數(shù)據(jù)傳輸速率、服務(wù)器處理器或內(nèi)存、數(shù)據(jù)庫分區(qū)等參數(shù)的調(diào)整是可以改善性能的。而其中的大多數(shù)都應(yīng)該由用戶主動地使用良好的網(wǎng)絡(luò)/系統(tǒng)管理工具運行網(wǎng)絡(luò)來實現(xiàn)。

現(xiàn)實世界的網(wǎng)絡(luò)

不幸的是，在其它的現(xiàn)實網(wǎng)絡(luò)參數(shù)中有著更多潛在的影響是上述調(diào)整所無法改善的。了解這些問題，既是科學(xué)的一部分也是藝術(shù)的一部分。其中有兩個一樣重要和關(guān)鍵的參數(shù)影響了在任意路徑進行互換的網(wǎng)絡(luò)吞吐量，即便終端系統(tǒng)是完美的：

A.往返延時（往返時間或者TCP語法中的RTT）

B.數(shù)據(jù)傳輸率限制

由于傳輸協(xié)議（如，TCP）存在錯誤恢復(fù)的限制，因此第一個參數(shù)的重要性與日俱增。而隨著傳輸數(shù)據(jù)的增加，第二個參數(shù)也越來越重要。兩者都與傳輸協(xié)議的行為互相作用。雖然往返延時似乎是直觀的，但是它與網(wǎng)絡(luò)路徑和協(xié)議參數(shù)之間的關(guān)系卻往往被漏掉。因此，我們必須了解哪些網(wǎng)絡(luò)協(xié)議參數(shù)可能與網(wǎng)絡(luò)路徑本身的屬性相互作用。

C.發(fā)送者的傳輸窗口（未確認(rèn)數(shù)據(jù)，第4層及以上）

D.發(fā)送者和接收者最大傳送單元（或“最大傳輸單元”——MTU，幀大?。?/P>

E.發(fā)送者的傳輸（第4層）超時時間和重傳策略

F.接收者的窗口（包緩沖大小）

G.接收者的確認(rèn)（ACK）策略（第4層及以上）

H.誤差檢查/糾正

I.路徑擁塞通知，如果有（第2層和更高層的）

J.資源負(fù)荷

這些是主要的協(xié)議棧參數(shù)和相關(guān)算法，它們允許在現(xiàn)實的、不完善的網(wǎng)絡(luò)路徑和終端性能中實現(xiàn)吞吐量最大化。但是，這并不意味著吞吐量將達到理想的最大化，而只是表示在一個指定的現(xiàn)實路徑，協(xié)議性能能夠調(diào)整（第1層和更高層）到對于該協(xié)議/路徑組合的最佳吞吐量——選擇一個不同的協(xié)議或路徑可能會很好地提高總體吞吐量。這就是網(wǎng)絡(luò)架構(gòu)師必須具備經(jīng)驗和知識以更好地設(shè)計的原因，同時也是網(wǎng)絡(luò)管理人員和技術(shù)人員必須精通性能測試和計算的原因。

下面這個統(tǒng)計圖表示在一條現(xiàn)實網(wǎng)絡(luò)路徑中發(fā)送成千上萬的實際網(wǎng)絡(luò)數(shù)據(jù)包以滿足一個用TCP/IP進行簡單但大型的文件傳輸請求：

左上角顯示傳輸1.5MB的流量花費了大約35秒時間，因此吞吐量是8 * 1500000 / 35 = 343 KBps，是一個典型的小T1連接速度，如ADSL上傳。但是——右下角顯示許多中轉(zhuǎn)包延時僅是8毫秒（MSEC），同時左下角顯示所有的數(shù)據(jù)包是1518字節(jié)——以太網(wǎng)的傳統(tǒng)MTU。這兩個事實意味著1518字節(jié)有時候可以每8毫秒，或者說滿T1（1.5MBps）傳送。顯然，在限制數(shù)據(jù)傳輸率（良好的）和實際吞吐量（不太好的）之間存在著差距。

每個數(shù)據(jù)包的協(xié)議開銷是18B + 20B + 20B （Ethernet + IP + TCP），因此傳輸每個數(shù)據(jù)包會折損掉1518 - 58 = 1460字節(jié)有效負(fù)載，而實現(xiàn)的最高的速度為8 * 1460 / .008 = 1.46Mbps：接近于T1，但是與觀察到的平均速度35秒有著很大的差距。這是怎么回事呢？我們的突發(fā)吞吐量接近于T1，但是我們所維持的平均吞吐量則還不到四分之一。

右邊的象限顯示了更多關(guān)于路徑的問題：

1.接收節(jié)點的確認(rèn)時間分布很廣泛，但是大多數(shù)速度都非?？欤ù蠹s200毫秒）——協(xié)議?；旧隙己芸?/P>

2.一些ACK時間非常長（延時ACK>100毫秒）——是什么原因呢？

3.經(jīng)常出現(xiàn)限制速率，但是更多的是，在右下角顯示一個相鄰包的廣泛傳播時間，即中轉(zhuǎn)到達時間——為什么？

網(wǎng)絡(luò)如何擁堵&延遲確認(rèn)字符（ACK）對網(wǎng)絡(luò)性能的影響

多種原因產(chǎn)生的多種結(jié)果

我們所看到的是多因素導(dǎo)致的多效性，這存在于典型的現(xiàn)實網(wǎng)絡(luò)。很明顯，“多少（限制的）數(shù)據(jù)傳輸率才足夠呢？”是一種誤導(dǎo)——具體問題要具體分析。如果我們的網(wǎng)絡(luò)總能保持1.5MB的傳輸帶寬，那么我們的等待時間是8秒而非35秒。但是，顯然，它并不總是這么大的，如右下角的測量結(jié)果。

原因1：網(wǎng)絡(luò)路徑擁塞。我們將路徑的T1部分共享給其它的流量，而且在此處的路由器/網(wǎng)橋會進行緩沖并延遲我們的數(shù)據(jù)包，有時候延遲會超過100毫秒。而且這種延時是非常多變的，因為相對應(yīng)的流量本身是可變的。顯然，統(tǒng)計分析是在這些情況下進行性能評估的唯一方法。

原因2：這是一個較簡單的問題——右上象限的延遲ACK。它們總和僅大于100毫秒。這是一個協(xié)議問題，是出現(xiàn)在接收者的TCP-棧參數(shù)設(shè)置的問題，但是這也與發(fā)送者發(fā)送TCP數(shù)據(jù)包的方式相關(guān)。這聽起來有點復(fù)雜，但實際上這是由于TCP是很老的協(xié)議，它仍帶有當(dāng)初為低速網(wǎng)絡(luò)設(shè)計的特性，那時消除“不必要”的數(shù)據(jù)包被認(rèn)為是很有用的。

因此，TCP仍然允許接收者只對每一個后續(xù)的數(shù)據(jù)包發(fā)送ACK（右上象限的點數(shù)量大約只有左上象限的一半）。當(dāng)然，接收到第N個數(shù)據(jù)包并不表示第N+1個也會出現(xiàn)，因此如果第N個沒有ACK，那么發(fā)送者將無法知道接收者是否收到了所有的數(shù)據(jù)。TCP中的解決方案（或kludge）是讓接收者在接收到每一個（如，奇數(shù)）沒有馬上ACK的數(shù)據(jù)包時開啟一個計時器。如果第N+1個數(shù)據(jù)包到達了，那么計時器就停止。如果計時器過期了，那么接收者將為最后一個接收的數(shù)據(jù)包發(fā)送一個ACK。

我們應(yīng)該給這個延時的ACK計時器參數(shù)賦一個什么值呢？其實，我們并不想讓發(fā)送者花費太長的時間等待延時ACK，因為這可能會導(dǎo)致它超時并轉(zhuǎn)到重發(fā)模式，這樣就會真正導(dǎo)致速度變慢。默認(rèn)的TCP參數(shù)值通常是100-150毫秒，并且不幸的是網(wǎng)絡(luò)技術(shù)人員往往無法達到這樣的要求。事情就這樣結(jié)束了嗎？不，增加的延時來源可能不被認(rèn)同，因為發(fā)送者的傳輸窗口可以設(shè)置為不發(fā)送一個奇數(shù)的數(shù)據(jù)包——通常參數(shù)都是可以調(diào)整的（后面會出現(xiàn)更多的類似情形）。

原因3的影響并不明顯，如右上象限所顯示：從200微秒到100毫秒的ACK延時的范圍。我們知道上下邊界不是網(wǎng)絡(luò)產(chǎn)生的，而是它們范圍內(nèi)的是又只是ACK路徑擁塞。這些延時與原因2有著相似的效果，但是因為ACK通常是小的數(shù)據(jù)包，而且在TCP中發(fā)送頻率只有數(shù)據(jù)發(fā)送一半，所以這些延時的效果是明顯的但并不算太糟糕。

這些單個延時因素一起導(dǎo)致產(chǎn)生變化的性能，這樣的性能只能進行統(tǒng)計性建模和估算。我們從上面的數(shù)據(jù)可以看到最大的延時是由于一個運行T1線路的特定的路由器/網(wǎng)橋的擁塞。如果路由器/網(wǎng)橋可以更快地操作，那么這條鏈路就夠用了，我們并不需要更多的數(shù)據(jù)傳輸率。但是如果不能，我們就需要一個更好的或者升級的路由器/網(wǎng)橋。

（NetCalibrator和NetPredictor）根據(jù)實際的網(wǎng)絡(luò)數(shù)據(jù)包生成的……如果對這里所述的各項原則已經(jīng)了解，并且可以在路徑上捕獲數(shù)據(jù)，那么諸如這樣的復(fù)雜工具并不總是需要的。

注意，分配到網(wǎng)絡(luò)路徑（從Percheron 到AFS08）上每個組件的數(shù)軸頂部曲線條反映了測量中必然的統(tǒng)計分布——不幸的是，正如我們現(xiàn)在知道的，這個工具的輸出顯示誤用了“帶寬”！同樣需要注意的是，這個網(wǎng)絡(luò)圖和組件屬性（速度，等等）允許我們用一個關(guān)鍵點的測量數(shù)據(jù)來估算所有的上述信息，如終端節(jié)點。我們所需要的是在任何路徑上找到延時來源，正是它們導(dǎo)致吞吐量損失的。

在這個例子中，網(wǎng)絡(luò)路徑是好的——我們知道這并不是網(wǎng)絡(luò)的原因。

NASA空間探測器、吞吐量&錯誤誤差率

NASA空間探測器與吞吐量

在我們更詳細地探討參數(shù)是如何影響吞吐量之前，讓我們先來考慮一個極端的例子：NASA必須與空間探測器和登陸車進行通信。在太空飛行時，詳細的無線命令-響應(yīng)事件和計算模型可以提供精確的航空器跟蹤定位。

但是，只有在我們理解了萬有引力、行星軌道和磁場以及其它影響，并且在這些知識的基礎(chǔ)上進行預(yù)測，我們才能獲得這個精確性。我們并不知道航天器在T時刻的所在位置，我們只能推測出T-t時刻它所在的位置以及狀態(tài)，這個時間是它向我們發(fā)出響應(yīng)的時刻。歷史數(shù)據(jù)，外加一個模型的輸出，這就是我們“現(xiàn)在”所談?wù)摰暮教炱魉诘奈恢?。對于火星航天器，t值大約是三分鐘：命令-響應(yīng)信號事件的RTT的一半。而對于木星，t值可能接近一個小時。

這樣也就不奇怪NASA登陸車沒有使用類似于視頻游戲的顯示和操縱桿來駕駛了。NASA工程師必須制造一個精確的模型，它使機器人才可以執(zhí)行他們發(fā)送的任何命令，同時他們還必須在同一時間將許多命令集合起來一起發(fā)出，這樣機器人才可以在我們的期限中準(zhǔn)確地完成任務(wù)。有一些發(fā)往火星的命令在過了6分鐘之后可能就“OK”了，但是毫無疑問Titan上的命令返回確認(rèn)需要2個小時的等待就不可行了。在這個極端的命令-響應(yīng)延遲環(huán)境中的關(guān)鍵是遠距離智能（如，導(dǎo)航），以及命令序列緩沖和我們終端上的遠距離建模。對這種情況的明智設(shè)計意味著我們將仍然必須等待，看機器人是否已經(jīng)到達巖石X并采取了該巖石的表層樣本，但是我們將不必發(fā)送更多的命令包脈沖來在一個RTT內(nèi)獲取到結(jié)果。

對于地球環(huán)境，我們最大的物理性延遲就是地球同步衛(wèi)星連接——1/4秒RTT。相比之下，一個跨越美國的租用地面連線所發(fā)出的命令響應(yīng)時間可能少于40毫秒。十年前，Bell Lab科學(xué)家們深入地研究了人們在電話通話時可以容忍多長時間，結(jié)果顯示50毫秒的延時是被認(rèn)為可以接受的。而更長的RTT將影響交談。對于計算機與計算機交換而言，大的RTT意味著更糟糕。

了解誤差概率

通過集合命令和數(shù)據(jù)、了解遠節(jié)點如何工作、以及認(rèn)知如何使用最佳協(xié)議（不是TCP/IP）來編碼數(shù)據(jù)以實現(xiàn)成功的外層空間傳輸，NASA解決了其吞吐量需求的問題。這里我們跳過了錯誤，但是吞吐量上未發(fā)現(xiàn)的和未改正的錯誤的影響仍然是重大的并且是協(xié)議無關(guān)的。為了減少錯誤意外的發(fā)生，NASA一直以來都使用糾錯代碼來保護價值數(shù)億——或數(shù)十億——美元的命令和數(shù)據(jù)。

我們的最后一個例子，在此包括基本協(xié)議和路徑屬性，如窗口、計時器、RTT、MTU和位/數(shù)據(jù)傳輸率，同時還添加了錯誤概率（誤碼率（BER））。不管網(wǎng)絡(luò)路徑是否達到1GBps非擁塞的數(shù)據(jù)傳輸率，如果10%的發(fā)送數(shù)據(jù)包丟失，那么吞吐量會變差。

在這種情況下，每秒鐘實際通過路徑的應(yīng)用數(shù)據(jù)數(shù)是受所選擇的傳輸協(xié)議（TCP、UDP、SCP、RTP……）以及配置的參數(shù)影響的。如果協(xié)議無法恢復(fù)丟失（如，UDP、VoIP），那么終端應(yīng)用必須進行恢復(fù)，這通常是非常緩慢或者基本不動。如果傳輸協(xié)議無法區(qū)分擁塞數(shù)據(jù)包丟失（如路由超載）和物理性錯誤丟失（如CRC錯誤），那么它將出現(xiàn)錯誤操作，包括使用錯誤的恢復(fù)算法和大規(guī)模減緩?fù)掏铝俊?/P>

速率延時乘積

一個重要且派生的路徑參數(shù)是速率延時產(chǎn)品（或稱為“帶寬延時乘積”）。這是有限的數(shù)據(jù)傳輸率（如T1）與相應(yīng)路徑的RTT的相乘值。從單位上看，我們知道是字節(jié)（比特）每秒乘以秒，得到一定的字節(jié)（或位）數(shù)。這表示在等待收到接收者的響應(yīng)（如一個ACK）時間內(nèi)，發(fā)送者可以在網(wǎng)絡(luò)路徑中加入多少數(shù)據(jù)。這是效率——也就是吞吐量——參數(shù)。在我們得到響應(yīng)之前，我們在路徑的限制傳輸率中發(fā)送更多的字節(jié)，在事務(wù)結(jié)束后我們就將得到更多的吞吐量。

對這個參數(shù)的計算可以讓我們知道如何設(shè)置發(fā)送者的傳輸窗口，是以數(shù)據(jù)包或是字節(jié)形式。速率延時乘積的概念說明了最終有多少數(shù)據(jù)包/字節(jié)總數(shù)會被填充到網(wǎng)絡(luò)路徑中，這樣就不會浪費不發(fā)送數(shù)據(jù)（等待）時間。人們通常都無法弄明白這個道理，但是，這是很重要的，如下例所示。

一個沮喪的網(wǎng)絡(luò)技術(shù)員發(fā)現(xiàn)安裝在同一個用戶的筆記本電腦上的相同的應(yīng)用，在兩個不同的公司上運行速率差別達到大約50%。網(wǎng)絡(luò)上有許多T1-T3線路，其中有一條是特別擁塞的。服務(wù)器和客戶筆記本電腦之間的距離大約是350到450英里——技術(shù)員帶著筆記本電腦在各處到處行走！從這些位置出發(fā)的路徑都是不同的，除非他們在路由器上配置一條T3鏈路到服務(wù)器的位置上，但是RTT都是60毫秒。應(yīng)用只是簡單地（通過TCP/IP）下載一個幾MB的銷售人員常用（和更新）的文件，但是一半以上的用戶都抱怨其緩慢的吞吐量（長時間延時）。在速度緩慢位置上，大約需要花費2分鐘來下載3.3MB。

注意上圖所示的吞吐量是很穩(wěn)定的，但是同時也該注意到累積包數(shù)據(jù)傳輸（紅色）與擬合線（黑色）之間的小偏差。吞吐量僅是217KBps，并且路徑上沒有任何線路是低于T1——幾乎是一個7：1吞吐量損失。為什么呢？對一個緩慢的客戶端和服務(wù)器上的數(shù)據(jù)包捕捉分析顯示：

1.在緩慢位置上，普遍有大約0.25%的數(shù)據(jù)包（2.5每1000）丟失在路徑上。

2.相應(yīng)這些丟失的重傳延時比典型的TCP棧還要長——大約每次2.5秒

3.在一個或兩個共享的T1連接上的負(fù)載過重且出現(xiàn)瓶頸，它們造成擁塞延時。

4.文件是使用TCP分割成大約31KB的SMB塊放到21全-MTU（1460字節(jié)有效負(fù)載）的數(shù)據(jù)包上發(fā)送出去的。由于每個塊的數(shù)據(jù)包是奇數(shù)的，接收者進入了延時ACK超時狀態(tài)，這樣它將最終一個塊的確認(rèn)每31KB延遲了150毫秒。

5.雖然速率延時乘積是T1 * 60 ms = 8.5， 1460字節(jié)數(shù)據(jù)包，但是服務(wù)器的傳輸窗口只有六個數(shù)據(jù)包，并且在沒有數(shù)據(jù)包丟失的情況下將不再增加。因此，服務(wù)器只使用70%可用的傳輸窗口。

上述的每一個因素都增加了客戶端數(shù)據(jù)傳輸?shù)难訒r。雖然頭兩個的來源是不一樣的（物理性vs.協(xié)議棧），但是用戶可以看到它們一起所產(chǎn)生了大量的數(shù)據(jù)塊延時。第三個觀察到的延時是先前所看到的延遲變化，同時可能還增加了一些由路由器超載所造成的數(shù)據(jù)包丟失，因此與第二個問題相互作用。第四個延時來源嚴(yán)格來說是接收者的TCP棧配置造成的，它分別在每個31KB塊傳輸中增加150毫秒而降低吞吐量。而其實這個過程原本只需花費165毫秒（包括協(xié)議總開銷）在T1線路上實現(xiàn)發(fā)送。最后一個因素嚴(yán)格來講也是TCP棧配置的問題，它理論上在每個塊中浪費了20毫秒，從而降低了吞吐量。但是，這通過強迫接收者在每一塊等待150毫秒ACK而被掩蓋了。

麻煩的TCP行為

當(dāng)終端跟蹤比較顯示物理數(shù)據(jù)包丟失發(fā)生時，網(wǎng)絡(luò)技術(shù)員將沿著與緩慢用戶位置相鄰的路徑檢查每個路由器接口的端口統(tǒng)計。果然，因為租用線路有缺陷，其中的一個接口出現(xiàn)了CRC錯誤。糾正這個問題可以消除最大的一個延時組件，同時因為TCP并不能確定數(shù)據(jù)包丟失是因為錯誤還是擁塞引起的，因此TCP只是減緩了發(fā)送者的速度，而不考慮數(shù)據(jù)包是如何丟失的。這是因為不管是TCP還是IP都沒有擁塞通知功能，而路由器都可以明確地向終端節(jié)點發(fā)出連接擁塞警告。

在快速恢復(fù)中，服務(wù)器端和客戶端的丟失跟蹤僅僅顯示出極少的嘗試。當(dāng)節(jié)點處察覺了丟失后，三次重復(fù)ACK僅僅發(fā)生了兩次，并且服務(wù)器卻并沒有做出快速重傳。結(jié)果是這樣的，不管服務(wù)器丟失了多少個數(shù)據(jù)包，它往往都需要花費2.5秒來恢復(fù)一個丟失。

這個圖繪制了上面吞吐量圖中的線之間的差（紅色=黑色-紅色），并且顯示（紅色）它與任何一秒上的平均吞吐量的差別。這樣提供了更好地流解析。藍色標(biāo)記只是表示每個21-數(shù)據(jù)包（31KB）SMB塊終止的位置（此處，延時ACK損失時間是150毫秒）。

如果不存在延時ACK，那么藍色標(biāo)記將會更緊密，紅色的曲線則是直線向下，而圖的長度將變短

藍色標(biāo)記之間的差距是由數(shù)據(jù)包丟失造成的。在160秒中存在14處1到2秒的差距。

向下斜的紅色曲線部分顯示吞吐量在丟失恢復(fù)后正在追趕——或超過——平均值。

紅色向下斜的部分大約比平均值快6，200Bps。因此，當(dāng)不存在數(shù)據(jù)包丟失時，每秒將傳輸27 KB + 6.2 KB = 33.2 KB數(shù)據(jù)。這將提高23%的吞吐量。需要明確的是：如果0.25%數(shù)據(jù)包丟失率可以減少20%吞吐量，要么重新配置TCP使用更新的恢復(fù)規(guī)則（通過Repeated Acks實現(xiàn)Fast Retransmission），要么考慮使用正確的傳輸協(xié)議，所以必須對每個傳輸流量的網(wǎng)絡(luò)接口保持高度的警惕性。

這些例子都說明了，作為一名建筑師、管理人員和技術(shù)人員都必須非常的細心：

1.了解備用物理網(wǎng)絡(luò)組件和鏈接的各個方面

2.了解備用網(wǎng)絡(luò)協(xié)議的各個方面

3.了解哪些工具可以用來查看網(wǎng)絡(luò)參數(shù)

4.了解在默認(rèn)和可配置參數(shù)上，供應(yīng)商的產(chǎn)品提供哪些協(xié)議棧

5.同時必須熱情對待用戶

記住，要做好一切的準(zhǔn)備，不只是去購買更快速交換機或租借更快的線路?。ū忍鼐W(wǎng)）