1. 背景情況

突然想起來很久以前聽部門一位同事說過，Http協(xié)議適用于廣域網(wǎng)，而TCP協(xié)議就不適用于廣域網(wǎng)，因為Http協(xié)議是短連接，而TCP協(xié)議是長連接，開銷比較大!

其實仔細(xì)分析就知道這種說話不成立。Http協(xié)議本身就是基于TCP協(xié)議的，發(fā)起一次Http請求之前客戶端需要同服務(wù)端通過三次握手建立TCP連接。

以下幾段內(nèi)容摘自網(wǎng)絡(luò)，***給出自己總結(jié)的結(jié)論。

2. 長連接與短連接

長連接與短連接的操作過程：

短連接的操作步驟是：建立連接——數(shù)據(jù)傳輸——關(guān)閉連接...建立連接——數(shù)據(jù)傳輸——關(guān)閉連接;

長連接的操作步驟是：建立連接——數(shù)據(jù)傳輸...(保持連接)...數(shù)據(jù)傳輸——關(guān)閉連接

長連接與短連接的使用時機：

長連接多用于操作頻繁，點對點的通訊，而且連接數(shù)不能太多的情況。每個TCP連接的建立都需要三次握手，每個TCP連接的斷開要四次握手。如果每次操作都要建立連接然后再操作的話處理速度會降低，所以每次操作下次操作時直接發(fā)送數(shù)據(jù)就可以了，不用再建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，頻繁的socket創(chuàng)建也是對資源的浪費。

短連接：web網(wǎng)站的http服務(wù)一般都用短連接。因為長連接對于服務(wù)器來說要耗費一定的資源。像web網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。試想如果都用長連接，而且同時用成千上萬的用戶，每個用戶都占有一個連接的話，可想而知服務(wù)器的壓力有多大。所以并發(fā)量大，但是每個用戶又不需頻繁操作的情況下需要短連接。

總之：長連接和短連接的選擇要視需求而定。

3. HTTP 1.1與HTTP 1.0的比較

一個WEB站點每天可能要接收到上百萬的用戶請求，為了提高系統(tǒng)的效率，HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請求都需要與服務(wù)器建立一個TCP連接，服務(wù)器完成請求處理后立即斷開TCP連接，服務(wù)器不跟蹤每個客戶也不記錄過去的請求。但是，這也造成了一些性能上的缺陷，例如，一個包含有許多圖像的網(wǎng)頁文件中并沒有包含真正的圖像數(shù)據(jù)內(nèi)容，而只是指明了這些圖像的URL地址，當(dāng)WEB瀏覽器訪問這個網(wǎng)頁文件時，瀏覽器首先要發(fā)出針對該網(wǎng)頁文件的請求，當(dāng)瀏覽器解析WEB服務(wù)器返回的該網(wǎng)頁文檔中的HTML內(nèi)容時，發(fā)現(xiàn)其中的圖像標(biāo)簽后，瀏覽器將根據(jù)標(biāo)簽中的src屬性所指定的URL地址再次向服務(wù)器發(fā)出下載圖像數(shù)據(jù)的請求，如圖3.3所示。

圖3.3

顯 然，訪問一個包含有許多圖像的網(wǎng)頁文件的整個過程包含了多次請求和響應(yīng)，每次請求和響應(yīng)都需要建立一個單獨的連接，每次連接只是傳輸一個文檔和圖像，上一次和下一次請求完全分離。即使圖像文件都很小，但是客戶端和服務(wù)器端每次建立和關(guān)閉連接卻是一個相對比較費時的過程，并且會嚴(yán)重影響客戶機和服務(wù)器的性能。當(dāng)一個網(wǎng)頁文件中包含Applet，JavaScript文件，CSS文件等內(nèi)容時，也會出現(xiàn)類似上述的情況。

為了克服HTTP 1.0的這個缺陷，HTTP 1.1支持持久連接，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。一個包含有許多圖像的網(wǎng)頁文件的多個請求和應(yīng)答可以在一個連接中傳輸，但每個單獨的網(wǎng)頁文件的請求和應(yīng)答仍然需要使用各自的連接。HTTP 1.1還允許客戶端不用等待上一次請求結(jié)果返回，就可以發(fā)出下一次請求，但服務(wù)器端必須按照接收到客戶端請求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個下載過程所需要的時間。基于HTTP 1.1協(xié)議的客戶機與服務(wù)器的信息交換過程，如圖3.4所示。

圖3.4

可見，HTTP 1.1在繼承了HTTP 1.0優(yōu)點的基礎(chǔ)上，也克服了HTTP 1.0的性能問題。不僅如此，HTTP 1.1還通過增加更多的請求頭和響應(yīng)頭來改進(jìn)和擴充HTTP 1.0的功能。例如，由于HTTP1.0不支持Host請求頭字段，WEB瀏覽器無法使用主機頭名來明確表示要訪問服務(wù)器上的哪個WEB站點，這樣就無法使用WEB服務(wù)器在同一個IP地址和端口號上配置多個虛擬WEB站點。在HTTP 1.1中增加Host請求頭字段后，WEB瀏覽器可以使用主機頭名來明確表示要訪問服務(wù)器上的哪個WEB站點，這才實現(xiàn)了在一臺WEB服務(wù)器上可以在同一個IP地址和端口號上使用不同的主機名來創(chuàng)建多個虛擬WEB站點。HTTP 1.1的持續(xù)連接，也需要增加新的請求頭來幫助實現(xiàn)，例如，Connection請求頭的值為Keep-Alive時，客戶端通知服務(wù)器返回本次請求結(jié)果后保持連接;Connection請求頭的值為close時，客戶端通知服務(wù)器返回本次請求結(jié)果后關(guān)閉連接。HTTP 1.1還提供了與身份認(rèn)證、狀態(tài)管理和Cache緩存等機制相關(guān)的請求頭和響應(yīng)頭。

HTTP 協(xié)議老的標(biāo)準(zhǔn)是HTTP/1.0，目前最通用的標(biāo)準(zhǔn)是HTTP/1.1。HTTP/1.1是在HTTP/1.0基礎(chǔ)上的升級，增加了一些功能，全面兼容 HTTP/1.0。HTTP/1.0不支持文件斷點續(xù)傳，目前的Web服務(wù)器絕大多數(shù)都采用了HTTP/1.1。

RANGE:bytes是HTTP/1.1新增內(nèi)容，HTTP/1.0每次傳送文件都是從文件頭開始，即0字節(jié)處開始。RANGE:bytes=XXXX表示要求服務(wù)器從文件XXXX字節(jié)處開始傳送，這就是我們平時所說的斷點續(xù)傳!

4. HTTP 1.1長連接與HTTP 1.0短連接

1. 背景

KeepAlive是就是通常所稱的長連接。KeepAlive帶來的好處是可以減少tcp連接的開銷，這對于短response body的請求效果更加明顯。同時，可以為采用HTTP協(xié)議的交互式應(yīng)用提供良好的session支持。

2. KeepAlive的原理

在HTTP1.0和HTTP1.1協(xié)議中都有對KeepAlive的支持。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能夠支持，而HTTP1.1默認(rèn)支持。

HTTP1.0 KeepAlive支持的數(shù)據(jù)交互流程如下：

a)Client發(fā)出request，其中該request的HTTP版本號為1.0。同時在request中包含一個header：”Connection：keep-alive“。

b)Web Server收到request中的HTTP協(xié)議為1.0及”Connection：keep-alive“就認(rèn)為是一個長連接請求，其將在response的header中也增加”Connection： keep-alive“。同時不會關(guān)閉已建立的tcp連接。

c)Client收到Web Server的response中包含”Connection： keep-alive“，就認(rèn)為是一個長連接，不close tcp連接。并用該tcp連接再發(fā)送request。(跳轉(zhuǎn)到a))

HTTP1.1 KeepAlive支持的數(shù)據(jù)交互流程如下：

a)Client發(fā)出request，其中該request的HTTP版本號為1.1。

b)Web Server收到request中的HTTP協(xié)議為1.1就認(rèn)為是一個長連接請求，其將在response的header中也增加”Connection： keep-alive“。同是不會關(guān)閉已建立的tcp連接。

c)Client收到Web Server的response中包含”Connection： keep-alive“，就認(rèn)為是一個長連接，不close tcp連接。并用該tcp連接再發(fā)送request。(跳轉(zhuǎn)到a))

5. 總結(jié)

由此可以推斷“TCP或者說長連接不適用于廣域網(wǎng)”的說法不成立。