其實你不知道什麼是網路性能

Python部落(python.freelycode.com)組織翻譯，禁止轉載，歡迎轉發。

帶寬只是問題的一部分

為何一個在區域網上運行良好的應用程序在廣域網中陷入癱瘓狀態？當你試圖從遠程文件共享中打開文檔或通過VPN遠程登錄到總部運行的應用程序時，你可能已經親身體驗到了這一點。為什麼一個在你的辦公室里運行良好的應用程序在廣域網上幾乎毫無用處？如果你認為這僅僅是因為廣域網沒有足夠的帶寬，那麼你是就不了解什麼是網路性能了。

思考一下如果這家總部設在歐洲的大型銀行，但是他們業務在北美洲的場景。這家銀行的首席信息官從業務部門得知了一個一流熱點事件，同時歐洲的用戶正跨越大西洋嘗試訪問一個重要的應用程序。性能非常差勁。在壓力之下，首席信息官指示他信任的網路管理員師來解決這個問題。網路管理員負責地調查，測量跨大西洋鏈路利用率和路由器隊列統計數據。他報告說，網路絕對沒有問題，因為只有3%的網路被利用。但首席信息官命令道，我不管，拓寬頻寬到兩倍，網路管理員照做了，又安裝了一個OC-3鏈接。然後，猜猜怎麼樣了，網路利用度變成了1.5%，但是程序的性能依舊很差。那個首席信息官並不知道網路性能是什麼。

在這個經常可能發生的案例中，信息技術經理們將廣域網差的程序性能歸因於帶寬不足，因為他們通常認為帶寬等同於網速。但是，即便帶寬在對整體數據最大量的限制上起到重要的作用，這些數據在指定時間內從一個地方轉移到另一個地方，但它僅僅是幾個影響程序性能因素中的一個。其他關鍵的因素有網路延遲、傳輸協議緩衝區管理、擁塞控制動態以及應用程序協議本身的設計，這些因素都非常影響性能以至於它們可以完全消除通過提升帶寬或者「性能」來升級網路帶來的有益影響。

滑動窗口協議

為了理解為什麼性能不僅僅是帶寬的問題，讓我們從分解傳輸協議的底層工作原理開始。你可能知道，一個典型的網路應用程序會使用

TCP/IP

協議來傳遞數據。TCP是一種先進的滑動窗口協議。發射端傳送一個或者多個信息包給接收端，它通過這種方式工作。當包成功發送併到達後，接收端會發送一個回復確認包回來發送端來表明它已經成功收到發送端發送的消息。在滑動窗口協議中，窗口大小指的是在沒有接收到確認包之前發送端所允許在網路中擁有的數據量。

考慮到大多數數據通過網際網路或者公司廣域網通過滑動窗口協議進行傳輸，那我們能對這種傳輸的表現有什麼思考呢？假設包始終是固定大小的，含p級位元組。我們可以用包的數量k來表示窗口的尺寸。窗口的尺寸w，就是簡單的k與p的乘積。現在，如果我們關心我們在某一時間段內可以通過網路傳遞多少的信息，那麼我們實際關心的就是在一段時間內窗口滑動的距離。

因此，為了確定傳輸率，我們需要計算那個窗口數據在網路中傳輸的比率，那是什麼意思呢，就是我們需要理解傳輸w比特數據需要花費多少時間。這相應的需要知道在發送端和接收端之間傳輸信息的時間，這也被叫做網路延遲或者延期。儘管延遲可以被測量為單向（源到目的地）或者雙向（源到目的地並返回）但是我們通常關心的是雙向延遲。這個值被稱作RTT（往返時延）。注意這個RTT一直隨時間變換，它很少時間是單向延遲的兩倍，但是通常上與那樣測量相近。

延遲從幾個不同的源中產生。首先，存在傳播時延，由自然因素控制。對於同軸電纜，比特信息以60%到90%的光速傳播，而對於射頻和光，它們實際上以光速傳播。

另一個影響延遲的因素是發送時延，它源於底層通信鏈的帶寬。比如，通過一個100比特每秒的網路鏈發送一個100比特的包需要1秒將完整的包注入網路。注意發送時延僅僅是注入包所需的時間，但它沒有說包到達目的地的額外時間。

延遲的最後一個組成部分是隊列延遲，它表示一個包必須在等待區域（例如路由器中的隊列）中等待的時間，而同時其他數據包被發送，直到該數據包的第一位到達通信鏈路。在許多情況下，包括互聯網，排隊延遲不容易測量並會迅速變化。

RTT

是所有這些延遲包括發送時延、傳輸延遲和排隊延遲的總和，並且是每個通信鏈路在正向和反向過程中發送端和接收端之間的路徑的延遲。

現在我們知道了RTT的所有元素，我們可以看看它是如何影響數據傳輸的性能。考慮到TCP在潛在的有損IP網路層上提供可靠的通信，必須有某種方法恢復意外丟失的數據。TCP通過重新發送數據包，就是在發送端重新發送網路中丟失的數據包來處理這種丟失。為了實現重新發送，TCP必須拷貝每一份已經注入網路但是還不知道有沒有剛好被接收端接收的數據。另一種說法是，TCP必須緩衝一個數據窗口副本（術語中我們稱為W），直到它接收到一個對它的確認為止。因此，緩衝區大小不允許比發送端可用的緩衝空間（即內存）大。實際系統中通常為每個TCP連接保留一個固定的內存池（通常稱為套接字緩衝區，一個應用程序可以修改的值）。

TCP

性能

加上重新傳輸窗口和RTT的概念，我們現在可以推理TCP的滑動窗口的通信方案的性能。讓我們假設發送端使用的窗口大小為100位元組。因此，發送端能夠向網路注入100位元組，但它必須等待，直到它接收到對應數據的ACK。在最快的情況下，發送端必須等待一個RTT的時間，因為只有發送的數據的ACK返回了，才能繼續下面的操作，不能更快了，此時發送端可以向網路注入接下來的100比特數據。

這種行為如何轉化成流率？在穩定狀態下，該方案每RTT大小的時間傳輸W位元組的時間，換成簡單的數學術語意味著流率等於w/ RTT。你可能還記得高中代數，函數y = 1 / x定義了一個雙曲線，這意味著流率隨著RTT增大像雙曲線一樣衰減。換句話說，當RTT變大，流率迅速下降。

那麼，為什麼不通過增加包的大小（p）或包的個數（k）來使窗口大小（W）達到相應的更大值，以獲得更好的流率？協議設計者很久以前就解決了這個問題，並得出結論，事實上，在給定的網路環境中，「最佳」窗口大小即為最大化網路流率。最好的窗口大小是一個使得發件人完全「填滿管道」的大小。「如果我們認為發送端和接收端之間的路徑作為一個管道，我們要計算它的體積，通過其「寬度」（它的流率，這更像它的橫截面積，以比特每秒為單位）乘以「長度」（單向延遲，以秒為單位）。由此產生的BDP（帶寬時延乘積）以比特為單位測量。換言之，管道大小表示在發送端和接收端之間「在線路上」物理傳輸的位的比特數目。

最佳窗口大小可以允許發送端保持傳輸，從而使網路一直保持充滿的狀態，始終攜帶數據（因此不會空閑和浪費時間）。這就好像是，在前進的方向有一個充滿了比特的管道，同時還有另外一個管道充滿了ACK指令。一旦第一個ACK到達，發送方向前滑動窗口，從而發送另一個包。如果窗口足夠大，ACK持續及時回到發件端，然後發送端也可以不斷發送新的包來維持最佳的流率。你可以認為這個過程中包在整個的傳送帶上運動，同時ACK在底部返回。

因此，實現最佳的流率僅僅需要發送端設置窗口的大小為RTT時間乘以網路帶寬。這應該很簡單，對吧？不幸的是，發送端會經常因為很多原因使用次優窗口。例如，像前面提到的那樣，發送端的緩衝區可能小於這個最佳大小，導致操作限制。

選用次優窗口的另一個原因是發送方可能會對其本身施加擁塞控制。這是長期存在的TCP研究領域，其中新方法經常出現。我只想說，擁塞控制過程是一個通過限制TCP窗口大小（通過在我們的方程減少K）實現的演算法，在網路中減少它到一個較小的值可以避免超載，或擁塞。當網路過載並丟失數據包時，TCP對應的減少窗口大小，從而有效地降低其整體發送速率。網路中，數據包丟失是擁塞的強烈指示，這個機制工作良好，並使每個發送端調整其窗口，從而分享得到一些網路帶寬，而不是無限制地使用盡量多的帶寬。對於其他網路（例如無線網路或衛星網路），丟失可能是數據損壞而不是擁塞造成的，這種技術可以人為地限制TCP的流率。這個問題也是一個

熱門的

研究領域。

另一個潛在的瓶頸可能出現在接收端。即使發送端能夠使用最佳窗口大小，接收端也可能沒有足夠的內存來同時保存和處理所有數據。為了處理這個流量控制問題，TCP在每個包中裝入一個稱為窗口建議的值，它實質上向發送端發出接收端願意接受多少額外數據的信號。如果接收端的緩衝區變滿或太小，接收端將窗口中的值降低到可控制的水平。此值最終可能小於最佳窗口大小，從而降低性能。

另外，最初TCP設計的特性會使建議的窗口大小小於所期望的值。因為在TCP報頭中的窗口建議欄位只分配了16位，可能的最大窗口被限制在65535比特中，對所謂的「大而胖的網路」（那些有大帶寬延遲產品）的性能有顯著的損害。幸運的是，在1992年，這個問題通過RFC1323以有趣的方式得到了提出和解決。該技術包括將TCP報頭中的窗口值

乘以2n

，其中n是被稱為窗口規模的一個新變數。在連接建立時間內，兩個TCP端點之間的n值被交換。當n允許的最大值為14時，TCP在窗口縮放時所能代表的最大窗口是230bytes（1 GB），比原來的65535位元組大很多。這種功能通常稱為有「大窗口」的TCP，現在由現代TCP自動協商實現。

程序性能

到目前為止，已經討論過的所有關於窗口大小的限制都是在終端系統中傳輸協議實現的結果。當我們查看應用程序性能時，會出現更多問題。例如，雖然應用程序通常可以自由選擇發送和接收緩衝區大小，但它們通常不簡單地依賴於操作系統提供的默認值大小。控制緩衝區大小的「旋鈕」通常隱藏在應用程序開發人員無法控制的軟體或中間件層的後面。即使應用程序有意配置緩衝區，程序員也必須選擇一些先驗值，但在開發時不能知道最佳大小，因為不同的終端主機在不同的網路路徑上進行通信，每個都需要一個不同的最優值。此外，關於應用程序如何以及何時設置這些緩衝區大小與其他連接設置功能的深奧細節可能會導致大窗口協商以程序員可能無法察覺的細微方式失敗。最後，針對特定的應用程序，使緩衝區不必要的加大大，會增加程序整體的端到端延遲和傷害，這對應用程序的性能並非幫助。這樣做也會增加繁忙伺服器上的內存壓力，所以不應鼓勵應用程序程序員使用如此大的緩衝區。

即使所有的緩衝區都是最佳設置，當網路有足夠的帶寬，TCP擁塞控制是完美工作的，應用程序大面積的應用性能仍會明顯因為應用程序協議本身受損。每個基於TCP的應用程序必須通過在可靠的TCP連接之上一些高級消息傳遞協議形式來實現。想像一下，當這種應用程序協議停止為網路上的傳輸提供數據時，TCP是如何運行的。當然，TCP本身停止發送。

儘管TCP具有克服窗口限制的各種技術和選擇，但它在應用程序中無法克服類似的問題。如果一個應用程序的協議涉及的請求和響應，並且如果不實施任何方式的「保持網路充滿狀態」（例如，允許多個未完成的請求存在），它可以被轉化為一種情況，這種情況下一個RTT的時間中它只能處理一個請求。這種「閑聊式」的應用程序行為會導致主機之間許多低效的來回交流，也導致了性能隨著RTT增加像雙曲線一樣減少，就像一個滑動窗口協議的流率。這是一個嚴重的後果，確實，用戶被迫使用不是為大RTT設計的應用程序，或者更普遍的，為大帶寬環境設計的程序。

很容易看出這些應用程序是如何變成通用的東西。簡而言之，很難構建一個在區域網上不好用的的應用程序協議。想想基於100 Mbps乙太網的區域網。區域網一般只在有限的範圍內運行，並引起有限的總延遲。假設在一個乙太網的往返時延是0.1毫秒（0.0001秒）。BDP有大約0.01 MB = 1.3 KB。對於1500位元組的乙太網包，1.3 KB表示大約一個包。它不用窗口縮放，很容易用TCP來表示，而且幾乎可以肯定它為默認緩衝區大小分配提供了充分的支持。事實上，因為最佳窗口的大小對於小的RTT而言只有一包大小，所以即便應用程序設計的不好，他還是能工作得很流暢。這種類型的應用程序在某些方面是最麻煩的，因為當他們從區域網到廣域網，RTT變大時，性能會顯著惡化。

區域網 vs 廣域網

如果我們將區域網方案與高速WAN方案進行比較，情況看起來有些不同。假設現在是80毫秒RTT、帶寬1 Gbps，我們有一個BDP約10 MB。用1500位元組的乙太網包架構，大約有7100包。在這種情況下，除非在每個層（通過傳輸應用程序）採取謹慎措施，以確保充分利用網路的傳輸能力，否則，想要充分利用網路可能是具有挑戰性的。

您可以使用乙太網或者您最喜愛的包抓取分析工具來檢查這些概念。設置它來查找TCP埠445上的流量，它允許您在操作中觀看Windows文件共享協議。然後做一些簡單的事情，就像用微軟Word軟體從網路文件共享中打開文檔。返回乙太網，它將解碼文件系統協議命令，並查看蹤跡。您所看到的可能會使您感到驚訝：在Word應用程序和文件伺服器之間來回運行的數百個命令，如果不是數千個的話，然後只需要打開並載入文件。根據該文件，你會看到Word打開和關閉幾次，以不連續的順序讀取文件的不同部分，讀取相同的數據超過一次，將數據複製到一個臨時文件，多次檢索相同文件的元信息和目錄等等。

每一個操作中都連續執行，它們需要在網路上來回往返。在區域網上這沒什麼大不了的：每次往返1000次，每次0.1次，是十秒。然而，在80毫秒的廣域網線路上，1000次往返超過一分鐘。即使你升級廣域網線路到45 Mbps的DS3或155 Mbps 的OC-3，它仍需要超過一分鐘的時間去打開文件。

如果你從本文中只取出一個概念，請記住網路性能而不是帶寬。畢竟開發具有良好流量性能的應用程序看似簡單但並不簡單。出現不好的表現有許多不同的原因：物理因素（RTT，包的丟失）、傳輸協議（有限的緩衝能力、有限編碼大窗口的能力，有限的接收應用程序運行速度）和應用層協議的動態。傳輸層或應用層執行得不夠好，很容易導致性能不佳。進一步挫敗我們的是，整個系統可能出現在區域網環境中運行的很好，但是在廣域網或其他高延遲環境中出現讓人難以忍受的慢速的情況。

本文旨在幫助人們弄清楚這些有時複雜的交互，以便終端用戶能夠從應用程序和中間件軟體開發人員對這些問題的深入理解中獲益。如果有的話，你現在可以說你知道什麼是網路性能了。

英文原文：http://queue.acm.org/detail.cfm?id=1066069

譯者：Yuandaodao

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 Python程序員 的精彩文章: