HTTP持久連接的方法

本篇內(nèi)容主要講解“HTTP持久連接的方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“HTTP持久連接的方法”吧!

我們知道HTTP協(xié)議采用“請求-應(yīng)答”模式，當(dāng)使用普通模式，即非Keep-Alive模式時，每個請求/應(yīng)答客戶和服務(wù)器都要新建一個連接，完成之后立即斷開連接（HTTP協(xié)議為無連接的協(xié)議）；當(dāng)使用Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive功能使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對服務(wù)器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接。
在HTTP1.0版本中，并沒有官方的標(biāo)準(zhǔn)來規(guī)定Keep-Alive如何工作，因此實(shí)際上它是被附加到HTTP1.0協(xié)議上，如果客戶端瀏覽器支持Keep-Alive，那么就在HTTP請求頭中添加一個字段Connection:Keep-Alive，當(dāng)服務(wù)器收到附帶有Connection:Keep-Alive的請求時，它也會在響應(yīng)頭中添加一個同樣的字段來使用Keep-Alive。這樣一來，客戶端和服務(wù)器之間的HTTP連接就會被保持，不會斷開（超過Keep-Alive規(guī)定的時間，意外斷電等情況除外），當(dāng)客戶端發(fā)送另外一個請求時，就使用這條已經(jīng)建立的連接。
在HTTP1.1版本中，默認(rèn)情況下所有連接都被保持，如果加入"Connection:close"才關(guān)閉。目前大部分瀏覽器都使用HTTP1.1協(xié)議，也就是說默認(rèn)都會發(fā)起Keep-Alive的連接請求了，所以是否能完成一個完整的Keep-Alive連接就看服務(wù)器設(shè)置情況。
由于HTTP1.0沒有官方的Keep-Alive規(guī)范，并且也已經(jīng)基本被淘汰，以下討論均是針對HTTP1.1標(biāo)準(zhǔn)中的Keep-Alive展開的。
注意：
HTTPKeep-Alive簡單說就是保持當(dāng)前的TCP連接，避免了重新建立連接。
HTTP長連接不可能一直保持，例如Keep-Alive:timeout=5,max=100，表示這個TCP通道可以保持5秒，max=100，表示這個長連接最多接收100次請求就斷開。
HTTP是一個無狀態(tài)協(xié)議，這意味著每個請求都是獨(dú)立的，Keep-Alive沒能改變這個結(jié)果。另外，Keep-Alive也不能保證客戶端和服務(wù)器之間的連接一定是活躍的，在HTTP1.1版本中也如此。唯一能保證的就是當(dāng)連接被關(guān)閉時你能得到一個通知，所以不應(yīng)該讓程序依賴于Keep-Alive的保持連接特性，否則會有意想不到的后果。
使用持久連接之后，客戶端、服務(wù)端怎么知道本次傳輸結(jié)束呢？兩部分：1.判斷傳輸數(shù)據(jù)是否達(dá)到了Content-Length指示的大??；2.動態(tài)生成的文件沒有Content-Length，它是分塊傳輸（chunked），這時候就要根據(jù)chunked編碼來判斷，chunked編碼的數(shù)據(jù)在最后有一個空chunked塊，表明本次傳輸數(shù)據(jù)結(jié)束，詳見這里。什么是chunked分塊傳輸呢？下面我們就來介紹一下。

Transfer-Encoding是一個用來標(biāo)示HTTP報(bào)文傳輸格式的頭部值。盡管這個取值理論上可以有很多，但是當(dāng)前的HTTP規(guī)范里實(shí)際上只定義了一種傳輸取值——chunked。
如果一個HTTP消息（請求消息或應(yīng)答消息）的Transfer-Encoding消息頭的值為chunked，那么，消息體由數(shù)量未定的塊組成，并以最后一個大小為0的塊為結(jié)束。
每一個非空的塊都以該塊包含數(shù)據(jù)的字節(jié)數(shù)（字節(jié)數(shù)以十六進(jìn)制表示）開始，跟隨一個CRLF（回車及換行），然后是數(shù)據(jù)本身，最后塊CRLF結(jié)束。在一些實(shí)現(xiàn)中，塊大小和CRLF之間填充有白空格（0x20）。
最后一塊是單行，由塊大小（0），一些可選的填充白空格，以及CRLF。最后一塊不再包含任何數(shù)據(jù)，但是可以發(fā)送可選的尾部，包括消息頭字段。消息最后以CRLF結(jié)尾。
一個示例響應(yīng)如下：

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk

1A
and this is the second one
0

注意：
chunked和multipart兩個名詞在意義上有類似的地方，不過在HTTP協(xié)議當(dāng)中這兩個概念則不是一個類別的。multipart是一種Content-Type，標(biāo)示HTTP報(bào)文內(nèi)容的類型，而chunked是一種傳輸格式，標(biāo)示報(bào)頭將以何種方式進(jìn)行傳輸。
chunked傳輸不能事先知道內(nèi)容的長度，只能靠最后的空chunk塊來判斷，因此對于下載請求來說，是沒有辦法實(shí)現(xiàn)進(jìn)度的。在瀏覽器和下載工具中，偶爾我們也會看到有些文件是看不到下載進(jìn)度的，即采用chunked方式進(jìn)行下載。
chunked的優(yōu)勢在于，服務(wù)器端可以邊生成內(nèi)容邊發(fā)送，無需事先生成全部的內(nèi)容。HTTP/2不支持Transfer-Encoding:chunked，因?yàn)镠TTP/2有自己的streaming傳輸方式（Source：MDN-Transfer-Encoding）。

到此，相信大家對“HTTP持久連接的方法”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！