1. 背景情況

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

其實(shí)仔細(xì)分析就知道這種說話不成立。Http協(xié)議本身就是基于TCP協(xié)議的，發(fā)起一次Http請(qǐng)求之前客戶端需要同服務(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í)機(jī)：

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

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

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

3. HTTP 1.1與HTTP 1.0的比較

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

圖3.3

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

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

圖3.4

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

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

1. 背景

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

2. KeepAlive的原理

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

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

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

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

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

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

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

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

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

5. 總結(jié)

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