B6-Haproxy 與 KeepAlive

時間 2019-11-24

原文原文鏈接

B6-Haproxy 與 KeepAlive
php

1. Haproxy 與 KeepAlive
2. KeepAlive的原理
3. 影響 Haproxy Keepalive的參數
4. 測試 Haproxy keepalive
5. HTTP協議的頭部字段

1. Haproxy 與 KeepAlive
KeepAlive 就是一般所稱的長鏈接,KeepAlive帶來的好處是能夠減小tcp鏈接的開銷,這對於短response body的請求效果更加明顯,同時能夠爲採用HTTP協議的交互式應用提供良好的session支持,Hapxoxy做爲一款開源的LoadBalance,老版本不能支持KeepAlive,不過自從1.4.dev5開始支持Client端的KeepAlive。

2. KeepAlive的原理 css

HTTP1.0和HTTP1.1協議中都有對KeepAlive的支持,其中HTTP1.0須要在request中增長"Connection: keep-alive" header纔可以支持,而HTTP1.1默認支持。html

HTTP1.0 KeepAlive支持的數據交互流程以下:
a)Client發出request,其中該request的HTTP版本號爲1.0,同時在request中包含一個header:"Connection: keep-alive"。
b)Web Server收到request中的HTTP協議爲1.0及"Connection: keep-alive"就認爲是一個長鏈接請求,其將在response的header中也增長"Connection: keep-alive",同時不會關閉已創建的tcp鏈接。
c)Client收到Web Server的response中包含"Connection: keep-alive",就認爲是一個長鏈接不close tcp鏈接,並用該tcp鏈接再發送request。(跳轉到a)

HTTP1.1 KeepAlive支持的數據交互流程以下:
a)Client發出request,其中該request的HTTP版本號爲1.1。
b)Web Server收到request中的HTTP協議爲1.1就認爲是一個長鏈接請求,其將在response的header中也增長"Connection: keep-alive"。同時不會關閉已創建的tcp鏈接。
c)Client收到Web Server的response中包含"Connection: keep-alive",就認爲是一個長鏈接,不close tcp鏈接,並用該tcp鏈接再發送request。(跳轉到a)

3. 影響 Haproxy Keepalive的參數

[no]option httpclose
Enable or disable passive HTTP connection closing
May be used in sections: defaults | frontend | listen | backend
                            yes   |    yes   |   yes |   yes
Arguments : none
默認的,客戶端與服務端的通信,HAProxy只作分析、日誌和分析每一個鏈接的第一個request;
若是設置了 "option httpclose",則會檢查雙向的http頭是否有"Connection: close",若是沒有則自動添加;
以保證每一個客戶端或服務端在每次傳輸後,都會主動關閉TCP鏈接,使HTTP傳輸處於HTTP close模式下;
任何 "Connection" 頭若是不是"close"都會被移除。

不多會有服務器不正確的忽略掉頭,即便收到"Connection: close"也不關閉鏈接,不然就是不兼容HTTP 1.0瀏覽器標準;
若是發生這種狀況,能夠使用"option forceclose",在服務端響應後主動關閉請求鏈接;
選項 "forceclose"還能夠及早釋放服務鏈接,而沒必要等到客戶端的應答確認。

這個選項能夠設置在frontend或backend上,只要其上能夠創建鏈接,若是同時設置了"option forceclose",那麼它比"httpclose"優先;
若是同時設置了 "option http-server-close",則會實現"option forceclose"的效果。

[no]option forceclose
Enable or disable active connection closing after response is transferred.
May be used in sections :   defaults | frontend | listen | backend
                               yes   |    yes   |   yes |   yes
Arguments : none
有的HTTP服務器收到"option httpclose"設置的"Connection: close",也不會關閉鏈接,若是客戶端也不關閉,鏈接會一直打開,直到超時;
這會形成服務器上同一時段內的大量鏈接,日誌中也會顯示較高的全局會話時間;
此時,能夠使用 "option forceclose",當完成響應時當即關閉對外的服務通道，該選項隱式打開httpclose選項;
須要注意,該選項容許解析完整的request 和 response,因此能夠很快關閉至服務器的鏈接,比httpclose更早釋放一些資源;
若是同時啓用了"option http-pretend-keepalive",雖然會禁止發送 "Connection: close"頭,可是依然會在整個response被接收後,關閉鏈接。

[no]option http-server-close
Enable or disable HTTP connection closing on the server side 啓用或禁止關閉服務端的HTTP鏈接
May be used in sections :   defaults | frontend | listen | backend
                               yes   |    yes   |   yes |   yes
Arguments : none
該選項設置server端爲HTTP鏈接關閉模式,並支持客戶端爲HTTP keep-alive的pipelining模式;
提供了最低的客戶端延遲和最快的服務端會話重用,以節省服務資源,相似"option forceclose";
還容許無keepalive能力的服務端在keep-alive模式下爲客戶端提供服務,可是須要符合 RFC2616;
須要注意的是,有些服務器遇到"Connection: close" 時並不老是執行關閉,那麼keep-alive 則沒法使用;
解決方法是啓用 "option http-pretend-keepalive".

keep-alive request time 存活請求時間爲超時時間,綁定 "timeout http-keep-alive" 或 "timeout http-request"的設置。
這個操做能夠設置在frontend或backend上,只要其上能夠創建鏈接,須要注意的是這個選項能夠與 "option httpclose"結合;
但 "option httpclose"優先級更高,結合後基本實現了forceclose的效果。

[no]option http-pretend-keepalive
Define whether haproxy will announce keepalive to the server or not
May be used in sections :   defaults | frontend | listen | backend
                               yes   |    yes   |   yes |   yes
Arguments : none
當聲明瞭 "option http-server-close" 或 "option forceclose", haproxy會在給server的request頭中添加 "Connection: close";
然而有些服務器看到這個頭,會返回未知長度的response,並自動避免chunked encoding,其實這是不對的;
它會阻止haproxy保持客戶端長鏈接,還會使客戶端或緩存接收了未完成的響應,卻認爲響應結束了;
設置 "option http-pretend-keepalive", haproxy會在服務器端保持長鏈接,服務端則不會出現前面的問題;
當haproxy獲取了完整的response, 纔會以相似forceclose的方式關閉服務端,這樣客戶端獲得一個普通的響應,鏈接也在服務端被正常關閉;
建議不將其設爲默認值,由於大部分服務器會在發送完最後一個包以後更高效的關閉鏈接,並釋放緩存;
並且網絡上的數據包也會略微下降總體的峯值性能,可是啓用該選項,haproxy會略微少作一些工做;
因此若是haproxy在整個架構中是個瓶頸,能夠啓用該操做,以節省CPU;
這個選項能夠設置在frontend或backend上,只要其上能夠創建鏈接;
這個選項能夠與 "option httpclose"結合, 使服務端keepalive,客戶端close,但並不建議這樣作。

在默認的狀況下haproxy與客戶端和服務端都是會話保持的了。若是有用戶A、B同時
訪問代理服務器，那麼極可能只有第一個用戶的header會被髮給服務器。能夠參考以下模型

4. 測試 Haproxy keepalive
注意:假如請求的url，包含1個css 和1個png
4.1 haproxy 代碼linux

  
  
  
  
   
   
   
   option httpclose

  
  
  
  
   
   
   
   option http-server-close

http://blog.test.com/
請求頭信息
GET / HTTP/1.1
Host: blog.test.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

響應頭信息
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 02 Nov 2012 05:24:30 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Powered-By: PHP/5.3.6
X-Pingback: http://blog.test.com/xmlrpc.php
Content-Encoding: gzip
Set-Cookie: SERVERID=blog01; path=/

http://blog.test.com/wp-content/themes/twentyeleven/style.css
請求頭信息
GET /wp-content/themes/twentyeleven/style.css HTTP/1.1
Host: blog.test.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/css,*/*;q=0.1
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://blog.test.com/
Cookie: SERVERID=blog01

響應頭信息
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 02 Nov 2012 05:24:30 GMT
Content-Type: text/css
Last-Modified: Wed, 18 Jul 2012 03:25:51 GMT
Transfer-Encoding: chunked
Vary: Accept-Encoding
Expires: Fri, 02 Nov 2012 06:24:30 GMT
Cache-Control: max-age=3600
Content-Encoding: gzip

http://blog.test.com/wp-content/themes/twentyeleven/p_w_picpaths/headers/pine-cone.jpg
請求頭信息
GET /wp-content/themes/twentyeleven/p_w_picpaths/headers/pine-cone.jpg HTTP/1.1
Host: blog.test.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: p_w_picpath/png,p_w_picpath/*;q=0.8,*/*;q=0.5
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://blog.test.com/
Cookie: SERVERID=blog01

響應頭信息
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 02 Nov 2012 05:24:30 GMT
Content-Type: p_w_picpath/jpeg
Content-Length: 39112
Last-Modified: Wed, 18 Jul 2012 03:25:51 GMT
Expires: Thu, 29 Aug 2013 05:24:30 GMT
Cache-Control: max-age=25920000
Accept-Ranges: bytes

注意:對比能夠發現，變動爲 http-server-close 參數後，響應頭信息沒有Connection: close 字段

5. HTTP協議的頭部字段
Accept：告訴WEB服務器本身接受什麼介質類型，*/* 表示任何類型，type/* 表示該類型下的全部子類型，type/sub-type。
Accept-Charset：瀏覽器申明本身接收的字符集
Accept-Encoding：瀏覽器申明本身接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate）
Accept-Language：瀏覽器申明本身接收的語言(語言跟字符集的區別：中文是語言，中文有多種字符集，好比big5，gb2312，gbk等等)
Accept-Ranges：WEB服務器代表本身是否接受獲取其某個實體的一部分（好比文件的一部分）的請求。bytes：表示接受，none：表示不接受。
Age：當代理服務器用本身緩存的實體去響應請求時，用該頭部代表該實體從產生到如今通過多長時間了。
Authorization：當客戶端接收到來自WEB服務器的 WWW-Authenticate 響應時，用該頭部來回應本身的身份驗證信息給WEB服務器。
Cache-Control：
    請求：
    no-cache（不要緩存的實體，要求如今從WEB服務器去取）
    max-age（只接受 Age 值小於 max-age 值，而且沒有過時的對象）
    max-stale：（能夠接受過去的對象，可是過時時間必須小於 max-stale 值）
    min-fresh：（接受其新鮮生命期大於其當前 Age 跟 min-fresh 值之和的緩存對象）
    響應：
    public(能夠用 Cached 內容迴應任何用戶)
    private（只能用緩存內容迴應先前請求該內容的那個用戶）
    no-cache（能夠緩存，可是隻有在跟WEB服務器驗證了其有效後，才能返回給客戶端）
    max-age：（本響應包含的對象的過時時間）
    ALL: no-store（不容許緩存）
Connection：
    請求：
    close（告訴WEB服務器或者代理服務器，在完成本次請求的響應後，斷開鏈接，不要等待本次鏈接的後續請求了）。
    keepalive（告訴WEB服務器或者代理服務器，在完成本次請求的響應後，保持鏈接，等待本次鏈接的後續請求）。
    響應：
    close（鏈接已經關閉）。
    keepalive（鏈接保持着，在等待本次鏈接的後續請求）。
    Keep-Alive：若是瀏覽器請求保持鏈接，則該頭部代表但願 WEB 服務器保持鏈接多長時間（秒）。例如：Keep-Alive：300
Content-Encoding：WEB服務器代表本身使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip
Content-Language：WEB 服務器告訴瀏覽器本身響應的對象的語言。
Content-Length： WEB 服務器告訴瀏覽器本身響應的對象的長度。例如：Content-Length: 26012
Content-Range： WEB 服務器代表該響應包含的部分對象爲整個對象的哪一個部分。例如：Content-Range: bytes 21010-47021/47022
Content-Type： WEB 服務器告訴瀏覽器本身響應的對象的類型。例如：Content-Type：application/xml
ETag：就是一個對象（好比URL）的標誌值，就一個對象而言，好比一個 html 文件，若是被修改了其 Etag 也會別修改;
      因此ETag 的做用跟 Last-Modified 的做用差很少，主要供 WEB 服務器判斷一個對象是否改變了;
      好比前一次請求某個 html 文件時，得到了其 ETag，當此次又請求這個文件時，瀏覽器就會把先前得到的 ETag 值發送給WEB 服務器;
      而後 WEB 服務器會把這個 ETag 跟該文件的當前 ETag 進行對比，而後就知道這個文件有沒有改變了。
Expired：WEB服務器代表該實體將在何時過時，對於過時了的對象，只有在跟WEB服務器驗證了其有效性後，才能用來響應客戶請求。
         是 HTTP/1.0 的頭部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT
Host：客戶端指定本身想訪問的WEB服務器的域名/IP 地址和端口號。例如：Host：rss.sina.com.cn
If-Match：若是對象的 ETag 沒有改變，其實也就意味著對象沒有改變，才執行請求的動做。
If-None-Match：若是對象的 ETag 改變了，其實也就意味著對象也改變了，才執行請求的動做。
If-Modified-Since：若是請求的對象在該頭部指定的時間以後修改了，才執行請求的動做（好比返回對象），不然返回代碼304，告訴瀏覽器該對象沒有修改。
If-Unmodified-Since：若是請求的對象在該頭部指定的時間以後沒修改過，才執行請求的動做（好比返回對象）。
If-Range：瀏覽器告訴 WEB 服務器，若是我請求的對象沒有改變，就把我缺乏的部分給我，若是對象改變了，就把整個對象給我。
          瀏覽器經過發送請求對象的 ETag 或者本身所知道的最後修改時間給 WEB 服務器，讓其判斷對象是否改變了。老是跟 Range 頭部一塊兒使用。
Last-Modified：WEB 服務器認爲對象的最後修改時間，好比文件的最後修改時間，動態頁面的最後產生時間等等。
Location：WEB 服務器告訴瀏覽器，試圖訪問的對象已經被移到別的位置了，到該頭部指定的位置去取。
Pramga：主要使用 Pramga: no-cache，至關於 Cache-Control： no-cache。例如：Pragma：no-cache
Proxy-Authenticate：代理服務器響應瀏覽器，要求其提供代理身份驗證信息。
Proxy-Authorization：瀏覽器響應代理服務器的身份驗證請求，提供本身的身份信息。
Range：瀏覽器（好比 Flashget 多線程下載時）告訴 WEB 服務器本身想取對象的哪部分。例如：Range: bytes=1173546-
Referer：瀏覽器向 WEB 服務器代表本身是從哪一個網頁/URL 得到/點擊當前請求中的網址/URL。例如：Referer：http://www.sina.com/
Server:WEB 服務器代表本身是什麼軟件及版本等信息。例如：Server：Apache/2.0.61 (Unix)
User-Agent:瀏覽器代表本身的身份（是哪一種瀏覽器）。
Transfer-Encoding: WEB 服務器代表本身對本響應消息體（不是消息體裏面的對象）做了怎樣的編碼，好比是否分塊（chunked）。
Vary:WEB服務器用該頭部的內容告訴 Cache 服務器，在什麼條件下才能用本響應所返回的對象響應後續的請求。
     假如源WEB服務器在接到第一個請求消息時，其響應消息的頭部爲：Content- Encoding: gzip; Vary: Content-Encoding;
     那麼 Cache 服務器會分析後續請求消息的頭部，檢查其 Accept-Encoding，是否跟先前響應的 Vary 頭部值一致,便是否使用相同的內容編碼方法;
     這樣就能夠防止 Cache 服務器用本身 Cache 裏面壓縮後的實體響應給不具有解壓能力的瀏覽器。例如：Vary：Accept-Encoding
Via：列出從客戶端到 OCS 或者相反方向的響應通過了哪些代理服務器，他們用什麼協議（和版本）發送的請求;
     當客戶端請求到達第一個代理服務器時，該服務器會在本身發出的請求裏面添加 Via 頭部，並填上本身的相關信息;
     當下一個代理服務器收到第一個代理服務器的請求時，會在本身發出的請求裏面複製前一個代理服務器的請求的Via 頭部;
     並把本身的相關信息加到後面，以此類推，當 OCS 收到最後一個代理服務器的請求時，檢查 Via 頭部，就知道該請求所通過的路由;
     例如：Via：1.0 236.D0707195.sina.com.cn:80 (squid/2.6.STABLE13)

附上：HTTP 1.1狀態代碼及其含義
狀態代碼狀態信息含義
100 Continue 初始的請求已經接受，客戶應當繼續發送請求的其他部分。（HTTP 1.1新）
101 Switching Protocols 服務器將聽從客戶的請求轉換到另一種協議（HTTP 1.1新）
200 OK 一切正常，對GET和POST請求的應答文檔跟在後面。
201 Created   服務器已經建立了文檔，Location頭給出了它的URL。
202 Accepted 已經接受請求，但處理還沒有完成。
203 Non-Authoritative Information 文檔已經正常地返回，但一些應答頭可能不正確，由於使用的是文檔的拷貝（HTTP 1.1新）。
204 No Content     沒有新文檔，瀏覽器應該繼續顯示原來的文檔。若是用戶按期地刷新頁面，而Servlet能夠肯定用戶文檔足夠新，這個狀態代碼是頗有用的。
205 Reset Content 沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容（HTTP 1.1新）。
206 Partial Content   客戶發送了一個帶有Range頭的GET請求，服務器完成了它（HTTP 1.1新）。
300 Multiple Choices 客戶請求的文檔能夠在多個位置找到，這些位置已經在返回的文檔內列出。若是服務器要提出優先選擇，則應該在Location應答頭指明。
301 Moved Permanently 客戶請求的文檔在其餘地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。
302 Found 相似於301，但新的URL應該被視爲臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀態信息是「Moved Temporatily」。
            出現該狀態代碼時，瀏覽器可以自動訪問新的URL，所以它是一個頗有用的狀態代碼。
            注意這個狀態代碼有時候能夠和301替換使用。例如，若是瀏覽器錯誤地請求http://host/~user（缺乏了後面的斜槓）;
            有的服務器返回301，有的則返回302。嚴格地說，咱們只能假定只有當原來的請求是GET時瀏覽器纔會自動重定向。請參見307。
303 See Other     相似於301/302，不一樣之處在於，若是原來的請求是POST，Location頭指定的重定向目標文檔應該經過GET提取（HTTP 1.1新）。
304 Not Modified 客戶端有緩衝的文檔併發出了一個條件性的請求（通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。
                   服務器告訴客戶，原來緩衝的文檔還能夠繼續使用。
305 Use Proxy     客戶請求的文檔應該經過Location頭所指明的代理服務器提取（HTTP 1.1新）。
307 Temporary Redirect 和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即便原來的請求是POST;
                         即便它實際上只能在POST請求的應答是303時才能重定向。因爲這個緣由，HTTP 1.1新增了307;
                         以便更加清除地區分幾個狀態代碼：當出現303應答時，瀏覽器能夠跟隨重定向的GET和POST請求；
                         若是是307應答，則瀏覽器只能跟隨對GET請求的重定向。（HTTP 1.1新）
400 Bad Request 請求出現語法錯誤。
401 Unauthorized 客戶試圖未經受權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示用戶名字/密碼對話框;
                  而後在填寫合適的Authorization頭後再次發出請求。
403 Forbidden 資源不可用。服務器理解客戶的請求，但拒絕處理它。一般因爲服務器上文件或目錄的權限設置致使。
404 Not Found 沒法找到指定位置的資源。這也是一個經常使用的應答。
405 Method Not Allowed 請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。（HTTP 1.1新）
406 Not Acceptable 指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容（HTTP 1.1新）。
407 Proxy Authentication Required 相似於401，表示客戶必須先通過代理服務器的受權。（HTTP 1.1新）
408 Request Timeout 在服務器許可的等待時間內，客戶一直沒有發出任何請求。客戶能夠在之後重複同一請求。（HTTP 1.1新）
409 Conflict 一般和PUT請求有關。因爲請求和資源的當前狀態相沖突，所以請求不能成功。（HTTP 1.1新）
410 Gone 所請求的文檔已經再也不可用，並且服務器不知道應該重定向到哪個地址。它和404的不一樣在於，返回407表示文檔永久地離開了指定的位置;
           而404表示因爲未知的緣由文檔不可用。（HTTP 1.1新）
411 Length Required 服務器不能處理請求，除非客戶發送一個Content-Length頭。（HTTP 1.1新）
412 Precondition Failed 請求頭中指定的一些前提條件失敗（HTTP 1.1新）。
413 Request Entity Too Large 目標文檔的大小超過服務器當前願意處理的大小。若是服務器認爲本身可以稍後再處理該請求;
                               則應該提供一個Retry-After頭（HTTP 1.1新）。
414 Request URI Too Long URI太長（HTTP 1.1新）。
416 Requested Range Not Satisfiable 服務器不能知足客戶在請求中指定的Range頭。（HTTP 1.1新）
500 Internal Server Error 服務器遇到了意料不到的狀況，不能完成客戶的請求。
501 Not Implemented 服務器不支持實現請求所須要的功能。例如，客戶發出了一個服務器不支持的PUT請求。
502 Bad Gateway 服務器做爲網關或者代理時，爲了完成請求訪問下一個服務器，但該服務器返回了非法的應答。
503 Service Unavailable 服務器因爲維護或者負載太重未能應答。例如，Servlet可能在數據庫鏈接池已滿的狀況下返回503。
                          服務器返回503時能夠提供一個Retry-After頭。
504 Gateway Timeout 由做爲代理或網關的服務器使用，表示不能及時地從遠程服務器得到應答。（HTTP 1.1新）
505 HTTP Version Not Supported 服務器不支持請求中所指明的HTTP版本。（HTTP 1.1新）

參考
nginx與haproxy負載均衡時處理keepalive與X-Forwarded-For的問題
http://blog.chinaunix.net/uid-20553497-id-3071866.html

HAproxy Client KeepAlive
http://blog.chinaunix.net/uid-10249062-id-163269.html

Haproxy參數配置
http://blog.163.com/guixl_001/blog/static/417641042011119115554441/

HAProxy 配置手冊 4.2 httpclose 相關
http://hi.baidu.com/maiyudaodao/item/c0bbd98f3b2820c0b17154e7

HTTP協議頭部與Keep-Alive模式詳解
http://a280606790.iteye.com/blog/1095085

HTTP的請求頭標籤 If-Modified-Since
http://tech.ddvip.com/2010-03/1269412477148135.html

HTTP 1.1與HTTP 1.0的比較
http://blog.csdn.net/elifefly/article/details/3964766數據庫

更多請：
linux 相關 274134275 , 37275208(已滿)
vmware 虛擬化相關 166682360瀏覽器

1. HTTPkeep-alive與TCP keepalive
2. keepalive
3. KeepAlive
4. keepalive+lvs，keepalive+nginx配置
5. Keepalive + LVS
6. lvs+keepalive
7. keepalive (2)
8. 【總結】Tcp Keepalive 和 HTTP Keepalive 詳解
9. nginx + keepalive
10. keepalive+LVS
更多相關文章...
• XSL-FO 與 XSLT - XSL-FO 教程
• PHP - AJAX 與 PHP - PHP教程
• Composer 安裝與使用
• Java Agent入門實戰（一）-Instrumentation介紹與使用

相關標籤/搜索

atlas+keepalive+lvs+mysql

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。