HTTP的持久串連對Web服務效能的影響

標籤：瀏覽器   伺服器效能   keep_alive   多線程   tcp串連   持久串連   

       我們的 Web 頁面通常有很多對像(Object)組成。如：jss 樣式表、圖片、scripts、文檔等。所以使用者瀏覽一個網頁檔案時候，要向 Web 服務器發送多次請求(要從伺服器上擷取一個Object就要向伺服器發送一個請求)，瀏覽器根據 jss 樣式表把從伺服器擷取的這些html頁面對象合成一個完整的html頁面展示給使用者。
        最早我們的瀏覽器是單線程的，意味著一次只能向瀏覽器發送一個Object請求，等到該Object傳輸完成了，再向服務發送第二個Object的請求。我們把它稱為串列交易處理。串列交易處理，使得我們的串連時延會疊加，使用者的體驗效果差。如，頁面有多幅圖片，頁面正在載入一幅圖片時，頁面上其它地方都沒有動靜，也會讓人門覺得很慢。後來出現了多線程的瀏覽器，當使用者點擊開啟一個頁面時，會同時向伺服器同時發起多個使用者請求(也就是平行處理方式)，減少了串連時延疊加，同時加速了一個web頁面對象的載入速度，讓使用者有更好的體驗效果。
        雖然採用多線程的瀏覽器加速了頁面的載入速度，但是如果我們只對串連進行簡單的管理(如不使用 keep alive)，瀏覽器每獲得一個Web對像都要使用一個新的TCP串連。
意思是說我們載入的html頁面有多少個頁面對象，瀏覽器與伺服器要建立多少條TCP串連。大家都知道使用TCP傳輸資料之前，要先經過三向交握，三向交握成功以後，雙方才能夠進行資料的傳輸。
所以說，我們使用TCP/IP進行資料網路傳輸必定會造成延遲的。雙方完成資料的傳輸以後還要經過TCP的四次斷開的過程。一個TCP的串連要經過：建立串連 、傳輸資料、拆除串連。

        TCP的建立串連和拆除串連是很費時的，有時候甚至比資料轉送的時間還長。所以，雖然瀏覽器採用了並發處理方式，加速了頁面的載入速度。但是請求一個頁面對像就需要與伺服器建立一條TCP串連。如果使用者瀏覽的分頁檔有1000個object的話，從伺服器請求資料到展示給使用者，

        最基本延遲時間 = 1000*(平均每個TCP串連建立時間 + 平均每個TCP串連拆除時間)。
隨著我們的頁面對像的增加，這個延遲時間是不斷增長的。用戶端每請求一個object，就要與伺服器建立一條TCP串連，伺服器每維護一條TCP串連是要消耗一定的資源(如記憶體)。所以，也加速了伺服器的負擔。對伺服器的並發使用者數也造成很大影響。所以後來 HTTP/1.1 使用了重用TCP串連功能來消除串連及關閉時延。允許HTTP裝置在交易處理結束之後將TCP串連保持在開啟狀態，
以便為後續的HTTP請求重用現存的TCP串連。在交易處理結束之後仍然保持在開啟狀態的TCP串連被稱為持久串連。也稱為 TCP 重用。

      是如何重用TCP串連的呢？
      假如，瀏覽的網頁檔案有400個object.我們的瀏覽器是4線程的，瀏覽器會並行向 Web 服務器發送4個 TCP串連請求。當這4個TCP請求與伺服器建立串連完成資料轉送以後，並不是
把它拆除掉。瀏覽器與web伺服器協定使用 keep-alive 功能時。HTTP裝置就會在交易處理結束之後將該4條TCP串連保持在開啟狀態。瀏覽器就使用這4條TCP串連完成後續的396個object的資料轉輸。
        持久串連降低了時延和串連建立的開銷，將串連保持在已調諧狀態，而且減少了開啟串連的潛在數量。但是，管理 持久串連時要特別小心，不然就會累積出大量的空閑串連，耗費用戶端和伺服器上的資源。下面是 Apache 網頁伺服器管理持久串連的一些配置：

[[email protected] ~]# vim /etc/httpd/extra/httpd-default.conf...#KeepAlive OnKeepAlive On## MaxKeepAliveRequests: The maximum number of requests to allow# during a persistent connection. Set to 0 to allow an unlimited amount.# We recommend you leave this number high, for maximum performance.# 保持串連允許傳輸的最大請求數MaxKeepAliveRequests 100# KeepAliveTimeout: Number of seconds to wait for the next request from the# same client on the same connection.# 在同一個用戶端的串連，等待下一個請求的逾時時間KeepAliveTimeout 5...

說明：

這些就是 Keep-Alive選項。
注意，Keep-Alive 首部只是請求將串連保持在活躍狀態。發出 keep-alive 請求之後，用戶端和伺服器並不一定會同意進行 keep-alive 會話。
它們可以在任意時刻關半閒置 keep-alive 串連，並可隨意限制 keep-alive 串連所處理事務的數量。

下面來看看，用戶端與伺服器怎樣商量它們是否使用HTTP協議的持久串連功能的呢？
實現 HTTP/1.0 keep-alive 串連的用戶端可以通過包含 Connection: Keep-Alive 首部請求將一條串連保持在開啟狀態。

通過 Google Chrome 瀏覽器的開發人員工具來查看，訪問 http://192.168.203.99/index.html 的要求標頭資訊。

Request HeaderAccept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Encoding:gzip,deflate,sdchAccept-Language:zh-CN,zh;q=0.8Cache-Control:no-cacheConnection:keep-alive     -----> 請求將一條串連保持在開啟狀態。Cookie:2c407_ol_offset=97; 2c407_ipstate=1402781651; 2c407_jobpop=0; 2c407_winduser=BD4OUFQKBQkLVgReBgsAAFsDVlMKB1MGUQ4LAwcFUlgBBms; 2c407_ck_info=%2F%09; 2c407_lastpos=index; 2c407_lastvisit=49%091402713397%09%2Findex.phpHost:192.168.203.99Pragma:no-cacheUser-Agent:Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

通過工具 crul 獲得的回應標頭資訊。

[[email protected] ~]# curl -I http://192.168.203.99/index.htmlHTTP/1.1 200 OKServer: nginx/1.0.11Date: Sat, 14 Jun 2014 09:17:15 GMTContent-Type: text/htmlContent-Length: 151Last-Modified: Thu, 01 May 2014 04:21:03 GMTConnection: keep-aliveAccept-Ranges: bytes

說明：
    如果伺服器願意為下一條請求將串連保持在開啟狀態(意思是說下一次請求資料時，可以通過該TCP串連傳輸資料，不需要建立新的TCP串連了)，
    就在響應中包含相同的首部 Connection: keep-alive。
    如果響應中沒有 Connection: keep-alive 首部，用戶端就認為伺服器不支援 keep-alive,會在發迴響應報文之後關閉串連@。
    從上在請求首部和響應首部分析，我們使用了HTTP 持久串連的功能。

總結：
   Keep-Alive 串連的限制和規則：
   1、在 HTTP/1.0 中，keep-alive 並不是預設使用的，用戶端必鬚髮送一個 Connection: Keep-Alive

         請求首部來啟用 keep-alive 串連。
   2、Connection: Keep-Alive 首部必須隨所有希望保持持久串連的報文一起發送。如果用戶端沒有發

         送 Connection: Keep-Alive 首部，伺服器就會在那條請求之後關閉串連。
   3、用戶端探明響應中沒有 Connection: Keep-Alive 響應首部，就可以知道伺服器發出響應之後是否

          會關閉串連了。
   4、為了避免出現大量的閒置TCP串連，要定義持久串連的逾時時間 timeout.  限制操持串連的TCP

         串連最多能完成多少個事務 MaxKeepAliveRequests

本文出自 “Linux” 部落格，請務必保留此出處http://9528du.blog.51cto.com/8979089/1426695