HTTP協議Keep-Alive詳解及問題

1、http的基礎知識

http是一個請求——響應模式的典型範例,即客戶端向服務器發送一個請求信息,服務器響應這個信息。

在老的http版本中:

每一個請求都創建一個TCP連接,當一次請求被響應後,tcp四次揮手,連接斷開。

這個模式的優點:

簡單,易實現,易理解,且滿足無連接的特點。

這個模式的缺點:

效率低。


HTTP /1.0

在這個版本的協議上,如果客戶端瀏覽器支持Keep-Alive,那麼就在HTTP請求頭部添加一個Connection:Keep-Alive,當服務器收到附帶Connection:Keep-Alive的請求,也會在響應頭部添加一個同樣的字段來使用Keep-Alive。這樣一來,客戶端和服務器端之間的TCP連接就會保持,不會斷開(超過Keep-Alive規定的時間,意外斷電等情況外),當客戶端發送另外一個到這個服務器的請求還是會使用這個已經建立的連接。


HTTP/1.1

在HTTP/1.1版本中,官方規定的Keep-Alive使用標準和在HTTP/1.0版本中有些不同,默認情況下所在HTTP1.1中所有連接都被保持,除非在請求頭或響應頭中指明要關閉:Connection: Close這也就是爲什麼Connection: Keep-Alive字段再沒有意義的原因。另外,還添加了一個新的字段Keep-Alive:,因爲這個字段並沒有詳細描述用來做什麼,可忽略它。


Not reliable(不可靠)

HTTP是一個無狀態協議,這意味着每個請求都是獨立的,Keep-Alive沒能改變這個結果。另外,Keep-Alive也不能保證客戶端和服務器之間的連接一定是活躍的,在HTTP1.1版本中也如此。唯一能保證的就是當連接被關閉時你能得到一個通知,所以不應該讓程序依賴於Keep-Alive的保持連接特性,否則會有意想不到的後果


Keep-Alive和POST

在HTTP1.1細則中規定了在一個POST消息體後面不能有任何字符,還指出了對於某一個特定的瀏覽器可能並不遵循這個標準(比如在POST消息體的後面放置一個CRLF符)。而據我所知,大部分瀏覽器在POST消息體後都會自動跟一個CRLF符再發送,如何解決這個問題呢?根據上面的說明在POST請求中禁止使用Keep-Alive,或者由服務器自動忽略這個CRLF,大部分服務器都會自動忽略,但是在未經測試之前是不可能知道一個服務器是否會這樣做。 


容易犯的誤區:

1、HTTP是一個無狀態面向連接的協議,無狀態不代表HTTP不能保持TCP連接,更不能代表HTTP使用的是UDP協議(無連接)

2、從HTTP/1.1起,默認都開啓了Keep-Alive,保持連接特性,簡單地說,當一個網頁打開完成後,客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一條已經建立的連接

3、Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的服務器軟件(如Apache)中設定這個時間



問題現象: 一個JSP頁面,居然要耗時40多秒。網頁中有大量的圖片的CSS

問題解決: 原因也找了半天,原來Apache配置裏面,把Keep-Alive的開關關閉了。這個是個大問題,工程師爲什麼要關閉它,原來他考慮的太簡單了,我們知道Apache適合處於短連接的請求,處理時間越短,併發數才能上去,原來他是這麼考慮,但是沒有辦法,只能這樣了,還是打開Keep-Alive開關吧。
當然,不是所有的情況都設置KeepAlive爲On。

下面的文字總結比較好:

在使用apache的過程中,KeepAlive屬性我一直保持爲默認值On,其實,該屬性設置爲On還是Off還是要具體問題具體分析的,在生產環境中的影響還是蠻大的。
KeepAlive選項到底有什麼用處?如果你用過Mysql ,應該知道Mysql的連接屬性中有一個與KeepAlive 類似的Persistent Connection,即:長連接(PConnect)。該屬性打開的話,可以使一次TCP連接爲同一用戶的多次請求服務,提高了響應速度。

比如很多網頁中圖片、CSS、JS、Html都在一臺Server上,當用戶訪問其中的Html網頁時,網頁中的圖片、Css、Js都構成了訪問請求,打開KeepAlive 屬性可以有效地降低TCP握手的次數(當然瀏覽器對同一域下同時請求的圖片數有限制,減少域名解釋的開銷),減少httpd進程數,從而降低內存的使用(假定prefork模式)。MaxKeepAliveRequests 和KeepAliveTimeOut 兩個屬性在KeepAlive =On時起作用,可以控制持久連接的生存時間和最大服務請求數。

不過,上面說的只是一種情形,那就是靜態網頁居多的情況下,並且網頁中的其他請求與網頁在同一臺Server上。當你的應用動態程序(比如:php )居多,用戶訪問時由動態程序即時生成html內容,html內容中圖片素材和Css、Js等比較少或者散列在其他Server上時,KeepAlive =On反而會降低Apache 的性能。爲什麼呢?
前面提到過,KeepAlive =On時,每次用戶訪問,打開一個TCP連接,Apache 都會保持該連接一段時間,以便該連接能連續爲同一client服務,在KeepAliveTimeOut還沒到期並且MaxKeepAliveRequests還沒到閾值之前,Apache 必然要有一個httpd進程來維持該連接,httpd進程不是廉價的,他要消耗內存和CPU時間片的。假如當前Apache 每秒響應100個用戶訪問,KeepAliveTimeOut=5,此時httpd進程數就是100*5=500個(prefork 模式),一個httpd進程消耗5M內存的話,就是500*5M=2500M=2.5G,誇張吧?當然,Apache 與Client只進行了100次TCP連接。如果你的內存夠大,系統負載不會太高,如果你的內存小於2.5G,就會用到Swap,頻繁的Swap切換會加重CPU的Load。
現在我們關掉KeepAlive ,Apache 仍然每秒響應100個用戶訪問,因爲我們將圖片、js、css等分離出去了,每次訪問只有1個request,此時httpd的進程數是100*1=100個,使用內存100*5M=500M,此時Apache 與Client也是進行了100次TCP連接。性能卻提升了太多。


總結
1、當你的Server內存充足時,KeepAlive =On還是Off對系統性能影響不大。
2、當你的Server上靜態網頁(Html、圖片、Css、Js)居多時,建議打開KeepAlive 。
3、當你的Server多爲動態請求(因爲連接數據庫,對文件系統訪問較多),KeepAlive 關掉,會節省一定的內存,節省的內存正好可以作爲文件系統的Cache(vmstat命令中cache一列),降低I/O壓力。
PS:當KeepAlive =On時,KeepAliveTimeOut的設置其實也是一個問題,設置的過短,會導致Apache 頻繁建立連接,給Cpu造成壓力,設置的過長,系統中就會堆積無用的Http連接,消耗掉大量內存,具體設置多少,可以進行不斷的調節,因你的網站瀏覽和服務器配置而異。


減少域名解釋的開銷
對於HTTP/1.0來說可以充分利用瀏覽器默認最大併發連接數比HTTP/1.1多的好 處,實現不增加新域名的開銷而更高的並行下載,減少域名解釋的開銷(注:IE 6,7在HTTP/1.0中默認最大併發連接數爲4,在HTTP/1.1中默認最大併發連接數爲2,IE8都爲6,Firefox2在HTTP/1.0中 默認最大併發連接數爲2 在HTTP/1.1中默認最大併發連接數爲8,firefox 3默認都是6),根據10年7月Google索引的42億個網頁的統計報告,每張網頁裏包含29.39個圖片,7.09個外部腳本,3.22個外部CSS 樣式表,如果設置了Keep-Alive並且合理控制Keep-Alive TimeOut這個參數可以大量的節約連接的開銷,提高相應速度。如果設置不好,在大併發的情況小,因維持大量連接而使服務器資源耗盡,而對於目前國內大 部分的用戶使用的還是IE6,7的情況下關閉Keep-Alive可以充分利用瀏覽器默認最大併發連接數的好處實現不增加額外的開銷頁面快速的展示。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章