HTTP權威指南閱讀筆記四：鏈接管理

　　HTTP通訊是由TCP/IP承載的，HTTP緊挨着TCP，位於其上層，因此HTTP事務的性能很大程度上取決於底層TCP通道的性能。

　　HTTP事務的時延

　　如圖：

　　

　　HTTP事務的時延有如下幾種主要緣由。

　　（1）客戶端首先須要根據URI肯定Web服務器的IP地址和端口號。若是最近沒有對URI中的主機名進行訪問，經過DNS解析系統將URI中的主機名轉換成一個IP地址可能要花費數十秒的時間。

　　（2）接下來，客戶端會向服務器發送一條TCP鏈接請求，並等待服務器回送一個請求接受應答。每條新的TCP鏈接都會有鏈接創建時延。這個值一般最多隻有一兩秒種，但若是有數百個HTTP事務的話，這個值會快速地疊加上去。

　　（3）一旦鏈接創建起來了，客戶端就會經過新創建的TCP管道來發送HTTP請求。數據到達時，Web服務器會從TCP鏈接中讀取請求報文，並對請求進行處理。因特網傳輸請求報文，以及服務器處理請求報文都須要時間。

　　（4）而後，Web服務器會回送HTTP響應，這也須要花費時間。

　　這些TCP網絡時延的大小取決於硬件速度、網絡和服務器的負載，請求和響應報文的尺寸，以及客戶端和服務器之間的距離。TCP協議的技術複雜性也會對時延產生巨大的影響。

 

　　性能聚焦區域

　　會對HTTP產生影響、最多見的TCP相關時延包括：

　　（1）TCP鏈接創建握手：HTTP事務越小，TCP鏈接創建握手所花時間佔的比例就越大。

　　（2）TCP慢啓動擁塞控制：TCP鏈接會隨着時間進行自我「調諧」，起初會限制鏈接的最大速度，若是數據傳輸成功，會隨着時間的推移提升傳輸速度，主要用於防止因特網的忽然過載和擁塞。因爲存在這種擁塞控制特性，因此新鏈接的傳輸速度會比已經交換過必定量數據的、「已調諧」鏈接慢一些。

　　（3）數據彙集的Nagle算法：TCP有一個數據流接口，應用程序能夠經過它將任意尺寸的數據放入TCP棧中——即便一次只放一個字節也能夠。因此若是TCP發送了大量包含少數數據的分組，網絡的性能就會嚴重降低。Nagle算法試圖在發送一個分組前，將大量TCP數據綁定在一塊兒，以提升網絡效率。這個算法會引起幾種HTTP性能問題。首先，小的HTTP報文可能沒法填滿一個分組，可能會由於等待那些永遠不會到來的額外數據而產生時延。其次，Nagle算法與延遲確認之間的交互存在問題——Nagle算法會阻止數據的發送，直到有確認的分組抵達爲止，但確認分組自身會被延遲確認算法延遲100~200毫秒。HTTP應用程序經常會在本身的棧中設置參數TCP_NODEALY，禁止Nagle算法，提升性能。若是要這麼作的話，必定要確保會向TCP寫入大塊的數據，這樣就不會產生一堆小分組。

　　（4）用於捎帶確認的TCP延遲確認算法：每一個TCP段都有一個序列號和數據完整性校驗和。每一個段的接收者收到完整的段時，都會向發送者回送小的確認分組。若是發送者沒有在指定的窗口時間內收到確認信息，發送者就認爲分組已被破壞或損毀，並重發數據。因爲確認報文很小，因此TCP容許在發往相同方向的輸出數據分組中對其進行「捎帶」。爲了增長確認報文找到同向傳輸數據分組的可能性，不少TCP棧都實現了一種「延遲確認」算法。延遲確認算法會在一個特定的窗口時間（一般是100~200毫秒）內將輸出確認存放在緩衝區中，以錄找可以捎帶它的輸出數據分組。若是在那個時間段內沒有輸出數據分組，就將確認信息放在單獨的分組中傳送。可是HTTP具備雙峯特徵的請求——應答行爲下降了捎帶信息的可能。當但願有相反方向回傳分組的時候，恰恰沒有那麼多。一般，延遲確認算法會引入至關大的時延。根據所使用操做系統的不一樣，能夠調整或禁止延遲確認算法。

　　（5）TIME_WAIT時延和端口耗盡：當某個TCP端點關閉TCP鏈接時，會在內存中維護一個小的控制塊，用來記錄最近所關閉鏈接的IP地址和端口號。這類信息只會維持一小段時間，一般是所估計的最大分端使用期的兩倍（稱爲2MSL，一般爲2分鐘）左右，以確保在這段時間內不會建立具備相同地址和端口號的新鏈接。實際上這個算法能夠防止在兩分鐘內建立、關閉並從新建立兩個具備相同IP 地址和端口號的鏈接。因爲可用源端口的數量有限（好比60000個），並且在2MSL秒（好比120秒）內鏈接是沒法重用的，鏈接速率就被限定在了60000/120 = 500 次/秒。超過這個數字，就會因端口耗盡而失敗。要修正這個問題，能夠把2MSL設置爲一個較小的值，或增長客戶端負載生成機器的數量，或確保客戶端和服務器在循環使用幾個虛擬IP 地址以增長更多的鏈接組合。