老李談HTTP1.1的長鏈接

老李談HTTP1.1的長鏈接

 

poptest是國內惟一一家培養測試開發工程師的培訓機構，以學員能勝任自動化測試，性能測試，測試工具開發等工做爲目標。若是對課程感興趣，請你們諮詢qq：908821478，諮詢電話010-84505200。

HTTP是一個構建在傳輸層的TCP協議之上的應用層的協議，在這個層的協議，是一種網絡交互須要遵照的一種協議規範。

 

HTTP1.0的短鏈接

HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。這個過程大概能夠描述爲：

一、創建鏈接：首先DNS解析過程。如把域名變成一個ip，若是url不包含端口號，則會使用該協議的默認端口號，HTTP協議的默認端口號爲80。而後三次握手創建一個TCP鏈接；

二、請求：鏈接成功後，開始向web服務器發送請求，這個請求通常是GET或POST請求。

三、應答：web服務器收到這個請求，進行處理。web服務器會把文件內容傳送給響應的web瀏覽器。包括：HTTP頭信息，體信息。

四、關閉鏈接：當應答結束後，web瀏覽器與web服務器必須四次握手斷開鏈接，以保證其它web瀏覽器可以與web服務器創建鏈接。

 

HTTP1.1的長鏈接

可是HTTP1.1開始默認創建的是長鏈接，即一旦瀏覽器發起HTTP請求，創建的鏈接不會請求應答以後馬上斷掉。

 

一、 一個複雜的具有不少HTTP資源的網頁會創建多少TCP鏈接，如何使用這些鏈接？

二、 已經創建的TCP鏈接是否會自動斷開，時間是多久？

 

對於第一個問題。如今瀏覽器都有最大併發鏈接數限制，應該說若是須要，就會盡可能在容許範圍內創建更多的TCP持久鏈接來處理HTTP請求，一樣滴，一個TCP持久鏈接能夠不斷傳輸多個HTTP請求，可是若是上一個請求的響應還未收到，則不能處理下一個請求(Pipeling管道技術能夠解決這個問題從而進一步提高性能)，因此說不少瀏覽器其實均可以修改容許最大併發鏈接數以提高瀏覽網頁的速度。

 

對於第二個問題。問題在於服務器端對於長鏈接的實現，特別是在對長鏈接的維護上。FTP協議及SMTP協議中有NOOP消息，這個就能夠認爲是心跳報文，但HTTP協議沒有相似的消息，這樣服務器端只能使用超時斷開的策略來維護鏈接。設想超時時間很是短，那麼有效空閒時間就很是短，換句話講：一旦鏈路上沒有數據發送，服務器端很快就關閉鏈接。

也就是說其實HTTP的長鏈接很容易在空閒後自動斷開，通常來講這個時間是300s左右。